Re: autogenerating headers & bki stuff - Mailing list pgsql-hackers

From Tom Lane
Subject Re: autogenerating headers & bki stuff
Date
Msg-id 15762.1248558081@sss.pgh.pa.us
Whole thread Raw
In response to Re: autogenerating headers & bki stuff  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Sat, Jul 25, 2009 at 10:56 AM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
>> I didn't realize this change was intending to throw all the Anum_
>> constants into a single header file. �I am strongly against that
>> on namespace pollution grounds,

> I don't really understand this objection.

It's for the same reasons we don't put all of include/catalog/ into one
giant header file, or all of include/ for that matter.  It's bad for
modularity, it's bad for compilation time, it's bad for rebuild time
if you're using --enable-depend.

> The reason why namespace
> pollution is bad is because there's a risk that someone might be using
> one of the names used for some other purpose,

Uh, no, that's actually pretty much irrelevant for our purposes.  As a
general rule, any two PG header files should be non-conflicting since
some .c file might need to include both.  So we'd have to get rid of
conflicts anyhow.  That does not make compartmentalization useless.
As a for-instance, exposing names that a given .c file doesn't really
need opens the door to typos that the compiler won't catch for you
(ie, accidentally using the wrong Anum_ constant, in this context).

> [ other straw-man argumentation snipped ]

None of this impresses me at all.  We should not throw a pile of
unrelated declarations into one header just to simplify the life
of an automatic script.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Jaime Casanova
Date:
Subject: Re: ECPG dynamic cursor, SQLDA support
Next
From: Jaime Casanova
Date:
Subject: Re: ECPG dynamic cursor, SQLDA support