Re: search_path vs extensions - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: search_path vs extensions
Date
Msg-id 8763fl4r1v.fsf@hi-media-techno.com
Whole thread Raw
In response to Re: search_path vs extensions  (Josh Berkus <josh@agliodbs.com>)
Responses Re: search_path vs extensions  (Andrew Dunstan <andrew@dunslane.net>)
Re: search_path vs extensions  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
Hi all,

Seems the night has been providing lots of thoughs :)

Josh Berkus <josh@agliodbs.com> writes:
> Sure.  I think that having better search path management would be a
> wonderful thing; it would encourage people to use schema more in general.
>
> However, that doesn't mean that I think it should be part of the extensions
> design, or even a gating factor.

First, this thread allowed us to go from: "we don't know where to install extensions" 
to: "we all agree that a specific pg_extension schema is a good idea, as  soon as user is free not to use it at
extensioninstall time".
 

So you see, search_path and extensions are related and thinking about
their relationship will help design the latter.

> search_path_suffix = 'pg_modules, information_schema'
> search_path = 'main,web,accounts'
>
> ... would mean that any object named would search in
> main,web,accounts,pg_modules,information_schema.  This would be one way to
> solve the issue of having extra schema for extensions or other "utilities"
> in applications.

That really seems exactly to be what we're proposing with pre_ and post_
search_path components: don't change current meaning of search_path,
just give DBAs better ways to manage it. And now that you're leaning
towards a search_path suffix, don't you want a prefix too?

Regards,
-- 
dim


pgsql-hackers by date:

Previous
From: "Markus Wanner"
Date:
Subject: Re: PostgreSQL Developer meeting minutes up
Next
From: Dimitri Fontaine
Date:
Subject: Re: search_path vs extensions