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

pgadmin has some umm, interesting queries over pg_depends. It sounds
like this change could complicate those. I doubt it's an
insurmountable problem of course.

On 9/21/08, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
>> Tom Lane wrote:
>>> A possible objection to this plan is that if the column-level privileges
>>> patch doesn't get in, then we're left with a useless column in
>>> pg_attribute. But an always-null column doesn't cost much of anything,
>>> and we know that sooner or later we will support per-column ACLs:
>>> they are clearly useful as well as required by spec. So any
>>> inefficiency would only be transient anyway.
>
>> Right. I don't see this objection holding much water as column privs are
>> something that many in the community would like to see. If Stephen's
>> patch doesn't get in, it is likely it would (or a derivative there of)
>> within the 8.5 release cycle. If anything it just provides a stepping
>> stone. I see nothing wrong with that.
>
> Yah. However, I started to look at doing this and immediately hit a
> stumbling block: we need a representation in pg_depend for a column's
> default expression (as distinct from the column itself). Currently
> this consists of classid = OID of pg_attrdef, objid = OID of the
> default's row in pg_attrdef; both of which would disappear if we
> get rid of pg_attrdef as an actual catalog.
>
> I can think of a way around that: represent a default expression using
> classid = OID of pg_attribute, objid = OID of table, objsubid = column
> attnum. This is distinct from the column itself, which is represented
> with classid = OID of pg_class. It seems pretty ugly and potentially
> confusing though. Also there would be a compatibility issue for clients
> that examine pg_depend. Is it ugly enough to scuttle the whole concept
> of merging pg_attrdef into pg_attribute?
>
> regards, tom lane
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com