Markus Wanner <[EMAIL PROTECTED]> writes:
> And why do we keep the attributes defaults in their own table with their
> own OID, instead of merging them into pg_attributes?
That has already been explained multiple times in this thread, but: the
default expression is a separate entity from the attribute itself, so
there needs to be some different representation for it in pg_depend.
Otherwise we couldn't handle the concept that dropping some entity
(like a function) forces discarding of the default, not the whole
column the default is attached to.
Now admittedly giving it its own OID and classid = pg_attrdef is
probably not the only way to do that. But merging it into the
pg_attribute row leaves no obvious way to do it within the
object identity representation that's been chosen for pg_depend.
> (Or put another way
> around: why do these need their own dependency tracking, while the ACLs
> don't?)
pg_shdepend is already designed to track ACLs: an ACL dependency says
that "there's some privilege that this role has been granted on this
object". So as long as you can identify the object you're okay, you
don't need a separate identity for the ACL.
> Or do we just want to keep the column-level privileges patch simple here
> and deferring other work to another patch?
Stephen was arm-waving about getting rid of pg_attrdef, but trying to
hold the column privileges patch hostage to that would be a serious
error. It's an independent problem, so it ought to be addressed in
a separate patch; and it has no clear solution so it's not entirely
obvious that it can or should be done at all.
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
