Re: search_path vs extensions

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, "David E(dot) Wheeler" <david(at)kineticode(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
Subject: Re: search_path vs extensions
Date: 2009-05-28 01:01:16
Message-ID: 4A1DE25C.6000301@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2009-05-28 01:07:15 Re: User-facing aspects of serializable transactions
Previous Message Jeff Davis 2009-05-28 01:00:53 Re: User-facing aspects of serializable transactions