Re: search_path vs extensions

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org, Josh Berkus <josh(at)agliodbs(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, "David E(dot) Wheeler" <david(at)kineticode(dot)com>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
Subject: Re: search_path vs extensions
Date: 2009-05-29 14:11:22
Message-ID: 4A1FED0A.40500@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut wrote:
> On Thursday 28 May 2009 02:57:00 Josh Berkus wrote:
>
>> Personally, if we're tracking stuff through special dependancies which
>> pg_dump will be aware of anyway, I don't see why extension objects
>> should go into a special schema.
>>
>
> But they clearly have to go into *some* schema, and it would add some clarity
> to the world if we made a recommendation which one that is. Which is what
> some of the subproposals really come down to.
>

Even that's going to be hard, frankly. The usage pattern is likely to be
too varied for any one-size-fits-all recommendation.

Proposals to allow a choice of schema at install time sound nice but in
practice they are a recipe for massive headaches and maintenance
nightmares, I think. It means no extension author will be able to
hardcode the schema name in any view, function etc. Yuck.

I think almost all these difficulties could be overcome if we had some
sort of aliasing support, so that arbitrary objects in schema a could be
aliased in schema b. If that were in place, best practice would
undoubtedly be for each module to install in its own schema, and for the
DBA to alias what is appropriate to their usage scenario. But unless
someone wants to tackle that I think we should leave schema management
entirely alone, and leave it up to the extension author / DBA between them.

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-05-29 14:27:27 Re: pg_migrator and an 8.3-compatible tsvector data type
Previous Message Michael Meskes 2009-05-29 13:54:26 Re: Warnings in compile