Re: More extension issues: ownership and search_path

Поиск
Список
Период
Сортировка
От Dimitri Fontaine
Тема Re: More extension issues: ownership and search_path
Дата
Msg-id m2lj1rwykr.fsf@2ndQuadrant.fr
обсуждение исходный текст
Ответ на Re: More extension issues: ownership and search_path  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: More extension issues: ownership and search_path  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: More extension issues: ownership and search_path  ("David E. Wheeler" <david@kineticode.com>)
Список pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Chris Browne
Дата:
Сообщение: Re: OpenVMS - an effort which needs guidance and support.
Следующее
От: Dimitri Fontaine
Дата:
Сообщение: Re: Range Types