Re: autogenerating headers & bki stuff

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: autogenerating headers & bki stuff
Date: 2009-07-25 14:56:50
Message-ID: 25254.1248533810@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-07-25 15:06:37 Re: SE-PostgreSQL Specifications
Previous Message Pavel Stehule 2009-07-25 14:30:37 Re: proposal: support empty string as separator for string_to_array