* Tom Lane ([EMAIL PROTECTED]) wrote: > 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?
Being able to handle a setup like that (though in pg_shdepend) might be
necessary anyway, depending on the approach we're happiest with for
column-level acl dependencies. Right now I've avoided it by just going
through all of the columns and the table level grantors/grantees and
listing them all when updating the dependencies. That keeps the
dependency system simple but complicates other things for it. I posed a
question previously about how people felt and don't recall there being
any response as yet.
Certainly, if we move to objid=table OID, objsubid=column attnum in
pg_shdepend, it strikes me that we should do the same in pg_depend where
appropriate, otherwise it'll just be a confusing inconsistancy.
Honestly, I really disliked the code which assumed pg_attribute had no
NULLable/toastable columns and used what seemed like pretty gruesome
hacks to create pg_attribute structures. I'd also really like to get
away from things which approached pg_attribute in that way, such as
pg_attrdef. If we were to accept the pg_attrdef approach, why aren't we
doing a pg_attracl table instead of adding a column to pg_attribute?
Thanks,
Stephen
signature.asc
Description: Digital signature
