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