Re: autogenerating headers & bki stuff

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sat, Jul 25, 2009 at 10:56 AM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)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