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

On Sun, Jul 26, 2009 at 11:31 AM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> 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.

Really?  I thought about that too, but concluded that it would be
easier to verify that a change to the BKI-generation stuff was correct
(by just diffing the generated files).  I don't know how to verify
that two versions of initdb do the same thing - I assume the databases
won't be byte-for-byte identical.  But that was my only concern about
it: I like the idea of expanding what can be done in BKI mode, if we
can figure out how to do it.

> 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.

If you think that the current system is anywhere close to ideal, I
give up.  To do so much as add a single line to pg_proc requires all
sort of useless manual work, like translating type names to OIDs, and
making sure that pronargs contains the correct value when the same
information is already encapsulated in both proargtypes and
proargmodes.

Introducing defaults for DATA() would bring some benefits because it
would mostly avoid the need to change every row in the file when
adding a new column.  But a preprocessing script can do much more
sophisticated transformations, like computing a value for a column, or
looking up type names in another file and translating them into OIDs.
It's not even hard; it's probably a 100-line patch on top of what I
already submitted.

...Robert