* Tom Lane ([EMAIL PROTECTED]) wrote: > Stephen Frost <[EMAIL PROTECTED]> 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
signature.asc
Description: Digital signature
