Re: Allowing extensions to find out the OIDs of their member objects - Mailing list pgsql-hackers

From Chapman Flack
Subject Re: Allowing extensions to find out the OIDs of their member objects
Date
Msg-id 5C4513AE.7050509@anastigmatix.net
Whole thread Raw
In response to Allowing extensions to find out the OIDs of their member objects  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Allowing extensions to find out the OIDs of their member objects  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 01/20/19 18:50, Tom Lane wrote:
> we make a catalog entry showing that object number three has OID
> thus-and-so, and then that catalog entry can be consulted to get
> the right OID (by C code that has hard-wired knowledge that object
> number three is the function it cares about).  This is still kind
> of messy, because aside from the hand-assigned object numbers
> you'd have to use the extension name as part of the lookup key,
> making the name into something the C code critically depends on.
> We don't have ALTER EXTENSION RENAME, so maybe that's okay, but
> it seems painful to say that we can never have it.

An extension *has* an OID, doesn't it? pg_extension has 'em.

If the extension script could somehow be informed at CREATE EXTENSION time
of what its OID is, that would clear the way for ALTER EXTENSION RENAME, no?

Somehow, I find this first idea more aesthetically appealing than
actually trying to bind things in extensions to fixed OIDs for all time.

-Chap


pgsql-hackers by date:

Previous
From: Andrew Gierth
Date:
Subject: Re: Allowing extensions to find out the OIDs of their member objects
Next
From: Tom Lane
Date:
Subject: Re: Allowing extensions to find out the OIDs of their member objects