On Mon, Sep 22, 2008 at 5:41 AM, Stephen Frost <[EMAIL PROTECTED]> wrote:
> * 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.. > That's exactly the impression i get also :) > > 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 > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAkjXBdkACgkQrzgMPqB3kijuVwCfU2C0TMgd1HYsaDY+wxRSTUph > YKsAnjtzysLoTpo3jWJMSxjmU23/RMaT > =OvBL > -----END PGP SIGNATURE----- > >
