Re: autogenerating headers & bki stuff - Mailing list pgsql-hackers

From Tom Lane
Subject Re: autogenerating headers & bki stuff
Date
Msg-id 27111.1248622263@sss.pgh.pa.us
Whole thread Raw
In response to Re: autogenerating headers & bki stuff  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: autogenerating headers & bki stuff
Re: autogenerating headers & bki stuff
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Sat, Jul 25, 2009 at 6:40 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
>> I'm not nearly as excited about migrating all or even most of, say,
>> the pg_proc DATA lines into SQL.

> I think it would actually buy you quite a bit to migrate them to SQL,
> because in SQL, default properties can generally be omitted, which
> means that a patch which adds a new property to pg_proc that takes the
> same value for every row doesn't actually need to touch the SQL at
> all.

[ shrug... ]  If you think default values would buy something in
maintainability, we could revise the BKI notation to support them,
with a lot less work and risk than what you're proposing.  Perhaps
something like

DATA_DEFAULTS( pronamespace=PGNSP proowner=PGUID prolang=12 ... );

DATA( oid=1242 proname=boolin pronargs=2 ... );
DATA( oid=1243 proname=boolout pronargs=2 ... );

with the convention that any field not specified in either the
DATA macro or the current defaults would go to NULL, except OID
which would retain its current special treatment.  (Hmm, I wonder
if we'd even still need the _null_ hack anymore?)

I remain unexcited about inventing contraptions that solve limited
special cases.  It's just not that hard to maintain those cases
the way we're doing now, and every added processing step introduces
its own comprehension and maintenance overheads.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: SE-PostgreSQL Specifications
Next
From: Andrew Dunstan
Date:
Subject: Re: autogenerating headers & bki stuff