Allow relocatable extension to use @extschema@?
Hi!
During work on knn-btree patchset we've faced the need to move
functions/operators from contrib to core [1]. In the extension
upgrade script we need to use @extschema@ in order to distinguish
contrib and core objects. However, it appears to be possible to use
@extschema@ only in non-relocatable extensions. Comment in
extension.c says: "For a relocatable extension, we needn't do this.
There cannot be any need for @extschema@, else it wouldn't be
relocatable.". I've explored that we've marked extension as
non-relocatable solely to use @extschema@ in script before [2].
So, it appears that comment in extension.c isn't true. There is at
least two precedents when relocatable extension needs to use
@extschema@. We've marked possibly relocatable extension as
non-relocatable once. And we could do it at the second time.
Extension relocatability doesn't seem to me much value to sacrifice.
But nevertheless should we allow relocatable extension to use
@extschema@. Any thoughts?
Links.
1. /messages/by-id/CAPpHfdsWsb9T1eHdX+r7wnXbGJKQxSffc8gTGp4ZA2ewP49Hog@mail.gmail.com
2. https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=de623f33353c96657651f9c3a6c8756616c610e4;hp=0024e348989254d48dc4afe9beab98a6994a791e
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Alexander Korotkov <a.korotkov@postgrespro.ru> writes:
But nevertheless should we allow relocatable extension to use
@extschema@. Any thoughts?
No. The reasoning in the comment still holds good: if you embed
@extschema@ in an object's definition, it becomes nonrelocatable.
regards, tom lane
On Tue, Dec 3, 2019 at 6:18 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Alexander Korotkov <a.korotkov@postgrespro.ru> writes:
But nevertheless should we allow relocatable extension to use
@extschema@. Any thoughts?No. The reasoning in the comment still holds good: if you embed
@extschema@ in an object's definition, it becomes nonrelocatable.
I see, allowing @extschema@ in non-relocatable extension provides easy
way to shoot yourself in the foot.
However, it might be still useful to be able to distinguish extension
and core object in upgrade script of relocatable extensions. What
about (optional) way to set search_path to @extschema@, pg_catalog
instead of just @extschema@?
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Tue, Dec 3, 2019 at 10:18 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Alexander Korotkov <a.korotkov@postgrespro.ru> writes:
But nevertheless should we allow relocatable extension to use
@extschema@. Any thoughts?No. The reasoning in the comment still holds good: if you embed
@extschema@ in an object's definition, it becomes nonrelocatable.
That's demonstrably false, and the links included in the OP prove it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Thu, Dec 05, 2019 at 09:52:50AM -0500, Robert Haas wrote:
On Tue, Dec 3, 2019 at 10:18 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Alexander Korotkov <a.korotkov@postgrespro.ru> writes:
But nevertheless should we allow relocatable extension to use
@extschema@. Any thoughts?No. The reasoning in the comment still holds good: if you embed
@extschema@ in an object's definition, it becomes nonrelocatable.That's demonstrably false, and the links included in the OP prove it.
Right. Or, to add further precision, embedding @extschema@ persistently in
the system catalogs does make the extension nonrelocatable. The OP examples
merely embed @extschema@ in extension scripts, and they don't impair
relocation. I'm okay with the proposal, but I still wouldn't mind deprecating
relocatable=true.