From: Jim Nasby <Jim.Nasby@BlueTreble.com>
To: Chapman Flack <chap@anastigmatix.net>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: tracking owner of extension-managed objects
Date: Thu, 31 Dec 2015 18:06:31 -0600
Message-ID: <5685C307.4020507@BlueTreble.com> (raw)
In-Reply-To: <5685A2E7.6080209@anastigmatix.net>
References: <56783412.6090005@anastigmatix.net>
<3486.1450720004@sss.pgh.pa.us>
<56785344.6080803@anastigmatix.net>
<56785C8C.6060006@anastigmatix.net>
<CA+TgmobBFoWaCJhiX_gXaPfXjucChJiVM8J0LRZ34eo=VvP03w@mail.gmail.com>
<567AFDD0.9090607@BlueTreble.com>
<5685A2E7.6080209@anastigmatix.net>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
On 12/31/15 3:49 PM, Chapman Flack wrote:
> On 12/23/15 15:02, Jim Nasby wrote:
>> >BTW, I've been pondering a very similar problem to this. I'm working on a
>> >metacoding framework, and it's inevitable that at some point it will want to
>> >know what objects it's created....
>> >
>> >I was planning on just making a best possible attempt and solving this in an
>> >extension via a combination of event triggers, reg* and other voodoo,
> In the voodoo department, I guess PL/Java could accompany each loading of
> a jar 'foo' with a 'CREATE TYPE sqlj.voodoo_foo AS ()' which is about as
> lightweight as it gets, and an extra regtype column in the jar_repository
> table could carry the Oid of that type.
Hmm, interesting idea.
> How well will pg_dump/restore handle that voodoo? I suppose they'll
> reliably recreate the types before loading the table with a regtype
> column, and by typing the column as regtype, the dump will refer to
> the type by name, and therefore work even if pg_dump is not given
> the --oids option?
Yes, assuming the type hasn't been dropped. Otherwise regtype spits out
the OID that used to be assigned, which AFAICT is completely useless for
a non-system object.
I've thought about creating a datatype that worked the same as the reg*
types, but also implemented a "foreign key" back to the relevant catalog
so things couldn't just vanish on you. (Since you obviously can't do an
FK to a catalog this would have to be simulated with event triggers).
> On 12/21/15 12:46, Tom Lane wrote:
>> >(I guess there are problems with extensions trying to do such things at
>> >all, since we don't provide a way for extensions to hook into the DROP
>> >mechanisms. Perhaps that should be fixed.)
>
> Ok, how numerous would be the problems with this:
>
>
> - The classid and refclassid columns (in both pg_shdepend and pg_depend)
> are currently Oid columns referencing pg_class.oid. The catalog
> definition would not preclude putting the oid of a non-system table
> there. The*documentation* says it has to be the oid of a system
> catalog, and surely there is code that currently would be surprised by
> an entry that wasn't (for example, default: elog(ERROR, "unrecognized
> object class..." in getObjectClass).
> But even now, looking at recordDependencyOn or shdepAddDependency,
> I don't see that the code would prevent such an entry being added.
Either I'm not understanding what you're saying here, or you're confused
about those two columns.
Those columns are there to tell you what *kind* of objects are involved
in the dependency. For example, a function will have two entries.
classid will be 1255 (pg_proc) for both of them. refclassid will be 2612
(pg_language) for one and 2615 (pg_namespace) for the other.
Oh, were you thinking of having a new classid that represented files on
disk?
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: Jim.Nasby@BlueTreble.com, chap@anastigmatix.net, robertmhaas@gmail.com, tgl@sss.pgh.pa.us
Subject: Re: tracking owner of extension-managed objects
In-Reply-To: <5685C307.4020507@BlueTreble.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox