pgadmin has some umm, interesting queries over pg_depends. It sounds like this change could complicate those. I doubt it's an insurmountable problem of course.
On 9/21/08, Tom Lane <[EMAIL PROTECTED]> wrote: > "Joshua D. Drake" <[EMAIL PROTECTED]> writes: >> Tom Lane wrote: >>> 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. > >> Right. I don't see this objection holding much water as column privs are >> something that many in the community would like to see. If Stephen's >> patch doesn't get in, it is likely it would (or a derivative there of) >> within the 8.5 release cycle. If anything it just provides a stepping >> stone. I see nothing wrong with that. > > Yah. However, I started to look at doing this and immediately hit a > stumbling block: we need a representation in pg_depend for a column's > default expression (as distinct from the column itself). Currently > this consists of classid = OID of pg_attrdef, objid = OID of the > default's row in pg_attrdef; both of which would disappear if we > get rid of pg_attrdef as an actual catalog. > > I can think of a way around that: represent a default expression using > classid = OID of pg_attribute, objid = OID of table, objsubid = column > attnum. This is distinct from the column itself, which is represented > with classid = OID of pg_class. It seems pretty ugly and potentially > confusing though. Also there would be a compatibility issue for clients > that examine pg_depend. Is it ugly enough to scuttle the whole concept > of merging pg_attrdef into pg_attribute? > > 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 > -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
