Re: Review: Extensions Patch - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Review: Extensions Patch
Date
Msg-id 17249.1291829120@sss.pgh.pa.us
Whole thread Raw
In response to Re: Review: Extensions Patch  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Review: Extensions Patch  (Robert Haas <robertmhaas@gmail.com>)
Re: Review: Extensions Patch  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> It's also worth noting that ALTER EXTENSION .. SET SCHEMA does NOT
> guarantee a correct relocation, because someone might have done ALTER
> FUNCTION .. SET search_path = @extschema@, and that's not going to get
> properly fixed up.  I'm coming to the conclusion more and more that
> ALTER EXTENSION .. SET SCHEMA just can't work reliably.

Dimitri's last reply to me
http://archives.postgresql.org/message-id/87r5ds1v4q.fsf@hi-media-techno.com
suggests that what he has in mind is to define a relocatable extension
as one that can be relocated ;-), ie it does not contain any such
gotchas.  Maybe this is too ugly in itself, or not useful enough to be
worth doing.  But it doesn't seem technically unworkable to me, so long
as relocatability is made an explicitly declared property of extensions.
It's certainly true that a large fraction of contrib modules should be
relocatable in that sense, because they just contain C functions that
aren't going to care.

Or are you complaining that somebody could break relocatability after
the fact by altering the contained objects?  Sure, but he could break
the extension in any number of other ways as well by making such
alterations.  The answer to that is privilege checks, and superusers
being presumed to know what they're doing.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "David E. Wheeler"
Date:
Subject: Re: Optimize PL/Perl function argument passing [PATCH]
Next
From: Tom Lane
Date:
Subject: Re: Solving sudoku using SQL