Tom Lane wrote:
Robert Haas <robertmh...@gmail.com> writes:
On Sat, Jul 25, 2009 at 6:40 PM, Tom Lane<t...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
