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

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > 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?
>
> That's actually not an unreasonable question.  If you were to do that
> then you could attach OIDs to the attribute ACLs, which might be a nicer
> representation in pg_shdepend than you were thinking of using.

What bugs me about this is that it comes across as poor database design-
both of these really are attributes of a column.  We're creating
seperate tables for each so we can induce a cleaner ID for them, which
just isn't the right approach imv.  This would also be another table to
go deal with when a column is removed, and a less-than-obvious place to
look for this information from the user's perspective.  It's also the
case that the items in these tables and the columns they're attached to
really are one-to-one, there's no many-to-one or one-to-many
relationship between them..

At the end of the day, this approach feels like more of a kludge to me
to keep the dependency system simple rather than making the dependency
system support the real-world system layout, which is that columns don't
have their own IDs.  Maybe we could approach this another way- what
about creating a new table which is pg_attrcolids that has both
pg_attrdef and pg_attracl rolled into it?  Then at least we're accepting
that we need a distinct ID for columns, but keeping them in one specific
place?  Is there a reason we would need a seperate ID for each?

It also strikes me to wonder about possible future support for
re-ordering columns, though I don't immediately see a way to use this as
a step towards supporting that.
Thanks,
    Stephen