Robert Haas <robertmh...@gmail.com> writes: > On Sat, Jul 25, 2009 at 3:21 AM, Peter Eisentraut<pete...@gmx.net> wrote: >> I think a less invasive change would be to include anum.h into all the >> catalog/pg_*.h headers, so that the external interface stays the same.
> Gah. I wish a toplevel make would build "contrib". > Anyway, yeah, we could do that. The downsides to that approach are: 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, quite aside from the massive #include restructuring it'd require. And then there's the fact that any change in such a file would force rebuild of just about the entire backend. I do not see any virtue in autogenerating the Anum_ constants anyway. Yeah, manually updating them is a bit of a pain, but it's only a tiny part of the work that's normally involved in changing a system catalog. In any case, practically all of the benefit involved could be gotten by just not having to mess with the numerical values of the individual constants. Which we could do by setting them up as enums instead of macros, along the lines of http://archives.postgresql.org/pgsql-committers/2008-05/msg00080.php 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
