Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group