I had a thought while looking over the column-level privileges patch
that Stephen Frost is working on. To wit, that the only reason that
column default expressions are stored in a separate catalog pg_attrdef
is the historical assumption in some parts of the code that pg_attribute
rows are fixed-width and all-not-null. This assumption is destroyed
by adding an attacl column, and so the patch has already done the
legwork to get rid of the assumption. Given that, it would be a lot
cleaner and more efficient to get rid of pg_attrdef and store column
default expressions in a new, possibly-null column
pg_attribute.attdefault.
For backwards compatibility for clients, we could create a system view
replacing pg_attrdef, but the backend wouldn't use it any more. Also,
although the atthasdef column is redundant with checking for non-null
attdefault, we should keep it: not only for compatibility, but because
it would be accessible in the fixed-width subset of pg_attribute rows
that will be kept in tuple descriptors, and so it could save a syscache
lookup in some places.
If that idea seems sane to people, what I would like to do is grab the
parts of the column-level privileges patch that relate to allowing
pg_attribute to contain null columns, and apply a patch that gets rid of
pg_attrdef and adds two columns attdefault and attacl to pg_attribute.
For the moment attacl would remain unused and always null. This would
eliminate a fair amount of the nuisance diffs that Stephen is currently
carrying and allow him to focus on the mechanics of doing something
useful with per-column ACLs. Adding both columns at the same time
should eliminate most of the merge problem he'd otherwise have from
needing to touch pg_attribute.h and pg_class.h again.
A possible objection to this plan is that if the column-level privileges
patch doesn't get in, then we're left with a useless column in
pg_attribute. But an always-null column doesn't cost much of anything,
and we know that sooner or later we will support per-column ACLs:
they are clearly useful as well as required by spec. So any
inefficiency would only be transient anyway.
Thoughts, objections?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
