| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
| Cc: | Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: IntArray in c.h |
| Date: | 2009-12-31 16:28:02 |
| Message-ID: | 439.1262276882@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> The definition of c.h is bogus anyway. You might think it contains
> includes and defines to set up a portable C environment, which is what
> the first half indeed does.
> But then things like regproc, transaction ID types, IntArray, varlena,
> bytea, oidvector, NameData, etc. do not belong there and should be moved
> to postgres.h.
Actually, what c.h does is to provide definitions that are needed in
both frontend and backend code. And we do NOT want to start including
postgres.h in frontend code. It might be that some of the declarations
there are useless to frontend code and could be moved, but trying to be
as strict as you suggest is only going to create problems.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2009-12-31 16:40:48 | Re: uintptr_t for Datum |
| Previous Message | Greg Stark | 2009-12-31 16:16:37 | Re: Serializable Isolation without blocking |