Re: Proposal: move column defaults into pg_attribute along with attacl

* Tom Lane (tgl@sss.pgh.pa.us) 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