Stephen Frost <sfrost@snowman.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.GD16005@tamriel.snowman.net.
[ 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
