From: | Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: IntArray in c.h |
Date: | 2010-01-03 03:40:54 |
Message-ID: | e08cc0401001021940w7c71c2cnd26f01ebc75f80ab@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2010/1/2 Peter Eisentraut <peter_e(at)gmx(dot)net>:
> On tor, 2009-12-31 at 11:28 -0500, Tom Lane wrote:
>> 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.
>
> I think the list above is a pretty good list of things that client code
> doesn't need, plus or minus a few things maybe.
>
Looking closer in c.h, there are several things to move or remove (and
it gets slightly more efficient if we do), but it seems we don't have
such motivation...
Regards,
--
Hitoshi Harada
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2010-01-03 04:13:09 | Re: Change to config.pl processing in the msvc build environment |
Previous Message | Greg Stark | 2010-01-03 03:06:50 | Re: So do we really *need* those substring() ops in tab-completion queries? |