Hi,
thank you for your patience in explaining. Rest assured that I've read
the relevant messages multiple times.
Tom Lane wrote:
> the
> default expression is a separate entity from the attribute itself,
That was the point I didn't understand...
> ..
> 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.
..and that finally provided the missing piece for my puzzle: it's not
the dependency between the attribute and its default which matters here.
But the possible dependencies of the default (and not the attribute
itself) on other entities.
> 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.
Understood, makes sense.
> 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.
Sure.
> 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.
Agreed.
Regards
Markus Wanner
