Re: More extension issues: ownership and search_path

Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> I think we'd better add an extowner column to pg_extension.

> Agreed. There's no need to have it now but we will add it at some
> point. So if now is when that works the best for you, I'm happy to see
> that happen:)

> Would it help that I prepare some of those modifications, as patches
> over the extension's patch that you started from?

No, I've hacked the code enough already that merging would be painful.
I'll keep working on it.

>> Another is the search_path setting. Currently this is actually rather
>> broken since pg_dump makes no effort at all to ensure that search_path
>> is the same at reload time as it was when the extension was created,
>> and thus the contained objects could easily go into the wrong schema.

> Well there's some code to place the extension's schema at the first
> place in the search_path before executing the script, already.

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.

> 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.

> 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.

regards, tom lane