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