Robert Haas <robertmhaas@gmail.com> writes:
> On Sat, Jul 25, 2009 at 3:21 AM, Peter Eisentraut<peter_e@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