Re: Review: Extensions Patch

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, "David E(dot) Wheeler" <david(at)kineticode(dot)com>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Review: Extensions Patch
Date: 2010-12-08 17:25:20
Message-ID: 17249.1291829120@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-12-08 17:31:47 Re: Solving sudoku using SQL
Previous Message David E. Wheeler 2010-12-08 17:21:05 Re: Optimize PL/Perl function argument passing [PATCH]