Re: search_path vs extensions - Mailing list pgsql-hackers

From Josh Berkus
Subject Re: search_path vs extensions
Date
Msg-id 4A1DE25C.6000301@agliodbs.com
Whole thread Raw
In response to Re: search_path vs extensions  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: search_path vs extensions  (Robert Haas <robertmhaas@gmail.com>)
Re: search_path vs extensions  (Dimitri Fontaine <dfontaine@hi-media.com>)
List pgsql-hackers
Tom,

> Well, we could certainly take that attitude and eliminate all this
> hassle ;-).  However, I think that more-flexible search path handling
> might have other uses, so I don't see any reason not to think about it.

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.

For example, I could see these kinds of settings:

search_path_override (suset) would set all users to a specific search 
path and raise an error at any set search_path attempts.  This would be 
mainly for secure applications.

search_path_suffix (suset) would append a certain set of schema to the 
end of the search path regardless of what else the user put in, e.g.:

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.

-- 
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: User-facing aspects of serializable transactions
Next
From: "Kevin Grittner"
Date:
Subject: Re: User-facing aspects of serializable transactions