Re: More extension issues: ownership and search_path

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: More extension issues: ownership and search_path
Date: 2011-02-07 17:20:52
Message-ID: m2lj1rwykr.fsf@2ndQuadrant.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> No, I've hacked the code enough already that merging would be painful.
> I'll keep working on it.

I supposed so much, but got to ask :)

> Oh, duh, I'd forgotten about the OverrideSearchPath usage. So never
> mind the above claim. But I still think it'd be a good idea to ensure
> that the search path is the same during dump/reload as it was the first
> time, and the current arrangement isn't going to ensure that.

Right. Something automated would be best (no user intervention), it
would force extension scripts to be self-contained or to explicitly
declare all their external dependencies. I'm in fact doping out
entirely my previous SET idea.

>> So while we said this is 9.2 material, if you want to tackle the whole
>> search_path at restore time issue (I did only the creation namespace,
>> thinking it would be enough) fully, you need dependency too.
>
> Quite aside from search path, cross-extension dependencies simply aren't
> going to work unless pg_dump knows about them so it can load the
> extensions in the right order. I had forgotten about the earthdistance
> case, but given that I think we probably can't put this issue off.

Well in fact the ordering already works because some earthdistance
objects depend on some cube objects, and pg_dump sees that in pg_depend.

>> I think we should then register some core components as extensions for
>> the sake of interdependencies here, too.
>
> Maybe that sort of refactoring could be done in 9.2 or further out.
> I don't see it happening for 9.1. I'm not really sure what the value
> is anyway.

Imagine that you wrote a set of plpgsql and plpythonu functions that you
want to maintain as an extension. You certainly want to mark that this
extension depends on the procedural languages being installed, right?

Also, I didn't bite this bullet, but maybe we should provide core PLs as
extension. Then CREATE LANGUAGE would maybe get deprecated and only
valid when used in an extension's script — or the next patch (UPGRADE)
will take care of create a plpythonu extension then attaching the PL
into it.

Again, pg_depend already allows pg_dump to create plpythonu before it
creates the extension that depends on it, though.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dimitri Fontaine 2011-02-07 17:23:32 Re: Range Types
Previous Message Robert Haas 2011-02-07 17:20:47 Re: limiting hint bit I/O