Re: autogenerating headers & bki stuff

Tom Lane 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.  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 kinda like this. It will make it easier not only to make catalog 
changes but to add entries to thinks like pg_proc (which is surely the 
biggest piece of the headache).

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

cheers

andrew