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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
