Skip site navigation (1) Skip section navigation (2)

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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, Stephen Frost <sfrost(at)snowman(dot)net>
Subject: Re: Proposal: move column defaults into pg_attribute along with attacl
Date: 2008-09-21 18:01:58
Message-ID: 29547.1222020118@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
"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

In response to

Responses

pgsql-hackers by date

Next:From: dpageDate: 2008-09-21 18:09:18
Subject: Re: Proposal: move column defaults into pg_attribute along with attacl
Previous:From: Joe ConwayDate: 2008-09-21 17:58:29
Subject: Re: [patch] fix dblink security hole

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group