Re: tracking owner of extension-managed objects - Mailing list pgsql-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