From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Chapman Flack <chap(at)anastigmatix(dot)net> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Allowing extensions to find out the OIDs of their member objects |
Date: | 2019-01-21 00:43:04 |
Message-ID: | 17423.1548031384@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Chapman Flack <chap(at)anastigmatix(dot)net> writes:
> 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.
Sure.
> 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?
And it remembers that where?
> Somehow, I find this first idea more aesthetically appealing than
> actually trying to bind things in extensions to fixed OIDs for all time.
I don't find it appealing particularly, but at least it hasn't got
any insurmountable-looking problems --- other than the "you can't
rename your extension" one. If we can't make the fixed-OIDs approach
work, this might be a workable second choice.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Imai, Yoshikazu | 2019-01-21 00:45:18 | RE: speeding up planning with partitions |
Previous Message | Tom Lane | 2019-01-21 00:38:36 | Re: Allowing extensions to find out the OIDs of their member objects |