Re: search_path vs extensions

Hi,

Le 29 mai 09 à 02:32, Robert Haas a écrit :
> On Thu, May 28, 2009 at 3:32 PM, Andrew Dunstan
> <andrew(at)dunslane(dot)net> wrote:
>> Tom Lane wrote:
>>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>>> It also seems to me that we're getting seriously sidetracked from
>>>> the
>>>> dependency-tracking part of this project which seems to me to be a
>>>> much deeper and more fundamental issue.
>>> I thought that part was a pretty simple problem, actually. Have an
>>> object representing the module, make sure each component object in
>>> the
>>> module has an AUTO dependency link to that object. Where's the
>>> difficulty?
>
> I think it's a simple problem too... except for the not-so-small
> detail of who is going to implement it.

I kind of said I'd do it, but it's going to be my first attempt to
patch backend code. Fortunately, Tom Dunstan did already a big chunk
of the work, but without user design approval first. I'm trying to
have user design voted, then I hope to reuse as much as Tom Dunstan's
work as possible :)
And Stephen Frost proposed to be helping too.

Maybe we could also open the road for a new way of contributing: have
someone discuss the user design on hackers until a consensus raises,
then have a developer happily code it without having to care about the
"politics" of it. :)

>> Well, yes. Honestly, I think all this search_path stuff is a red
>> herring. We
>> are once again in danger of over-designing this instead of doing
>> the simple
>> thing first (namely, don't worry about the search_path).
>
> Right.

My feeling is that current way of using extensions is tightly coupled
with search_path, and I'm not sure providing a SQL visible extension
object with dependancies will make this problem any easier.
Now I agree that we certainly can complete the extension support
project without having a single thought about schemas and search_path,
this problem can be postponed. I figured out it could guide some
extension user API design, but let's pretend all of this is orthogonal.

Still, extension users will want to have a default schema where the
extension is installed, and a way to override it, right?

Moving to extension user design per-se on Tuesday, trying to avoid
schema discussions while doing so.

Regards,
--
dim