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
