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

On Mon, Sep 22, 2008 at 5:41 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:

> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> > Stephen Frost <sfrost(at)snowman(dot)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..
>
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-----
>
>