Re: Another thought about search_path semantics - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Another thought about search_path semantics
Date
Msg-id 21810.1396634333@sss.pgh.pa.us
Whole thread Raw
In response to Re: Another thought about search_path semantics  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: Another thought about search_path semantics
List pgsql-hackers
Andres Freund <andres@2ndquadrant.com> writes:
> On 2014-04-04 13:33:59 -0400, Tom Lane wrote:
>> It strikes me that the real issue here is that the analogy to PATH is
>> fine for search_path's role as a *search* path, but it's not so good for
>> determining the creation target schema.  I wonder if we should further
>> redefine things so that the creation target schema is always the first
>> thing named in search_path, and if that doesn't exist, we throw an
>> error rather than silently creating in some schema further down the
>> list.

> Wouldn't that devolve into an even messier behaviour because of the
> historical "$user",public search path?

Ugh, right.  I think we had this discussion before actually, I'd just
forgotten it.

> I wonder if we could extend the search path syntax to specify whether a
> schema should be used for creation of objects or not. Sounds somewhat
> nasty, but I don't really have a better idea :(. Something like
> search_patch=public,!pg_catalog.

Hm ... doesn't fix the problem for existing dump files, which are going to
say "search_path = foo, pg_catalog".  However, we could modify it a bit,
so that the marker is put on schemas that can be skipped if missing for
creation purposes.  Then the default could look like "search_path =
!$user, public", while we still get safe behavior for pg_dump's commands.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Another thought about search_path semantics
Next
From: Josh Berkus
Date:
Subject: Re: Another thought about search_path semantics