Robert Haas <robertmh...@gmail.com> writes: > On Sat, Jul 25, 2009 at 10:56 AM, Tom Lane<t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers