From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Proposal: move column defaults into pg_attribute along with attacl |
Date: | 2008-09-22 02:41:29 |
Message-ID: | 20080922024129.GD16005@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* 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..
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-09-22 02:41:46 | Re: [patch] fix dblink security hole |
Previous Message | Joe Conway | 2008-09-22 02:26:26 | Re: [patch] fix dblink security hole |