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: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Markus Wanner <markus(at)bluegap(dot)ch>, "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-23 14:07:16
Message-ID: 27907.1222178836@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Stephen Frost <sfrost(at)snowman(dot)net> writes:
>> Huh?  Maybe I missed something, but I didn't think that was suggested
>> anywhere.

> I had suggested a single table, with an OID, which would house anything
> that needed a seperate OID for columns (defaults and ACLs currently) in
> 20080922024129(dot)GD16005(at)tamriel(dot)snowman(dot)net(dot)

[ squint... ]  But the default needs its *own* OID, because it is a
distinct entity for dependency purposes.  I think you're just confusing
two separate issues there.  If we did drop the "object/subobject" model
and just give attributes their own OIDs, we'd still need to give a
separate OID to each default; but ACLs wouldn't have their own OIDs.

The DROP issue I was complaining about could certainly be solved with
some uglification of the dependency-chasing code, so as far as the
backend is concerned it might be about a wash.  But there is enough
client-side code out there that roots around in pg_depend for
information we don't store any other way that I'm pretty hesitant to
change the pg_depend representation now.  I think adding a subobject
column to pg_shdepend is probably the best answer --- we only didn't
do that to start with because we thought it wasn't needed.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Gregory StarkDate: 2008-09-23 14:38:40
Subject: Re: Initial prefetch performance testing
Previous:From: Tom LaneDate: 2008-09-23 13:56:33
Subject: Re: pg_type.h regression?

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