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
