Date: Mon, 2 Jun 2014 15:00:53 -0700 (PDT)
From: David G Johnston <david.g.johnston@gmail.com>
To: pgsql-admin@postgresql.org
Message-ID: <1401746452731-5805809.post@n5.nabble.com>
In-Reply-To: 
 <CAJYcdTuW815KJ6enWLxNY__ZD5HJOuThmDhJT4i4b541TFL8=Q@mail.gmail.com>
References: 
 <CAJYcdTuW815KJ6enWLxNY__ZD5HJOuThmDhJT4i4b541TFL8=Q@mail.gmail.com>
Subject: Re: set search_path command
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-admin-owner@postgresql.org

Radovan Jablonovsky wrote
> Hello,
> 
> When we compared behaviour of "set search_path" between 9.1.9 and 9.3.4,
> there is difference. On 9.1.9 the command "set search_path to
> schema1,public" checks if the schema exists and if not it return error.
> Example:
> set search_path to "schema123",public;
> ERROR:  invalid value for parameter "search_path": "schema123, public"
> DETAIL:  schema "schema123" does not exist
> 
> On 9.3.4 the same command silently ignore the schema does not exists.
> Example:
> set search_path to "schema123",public;
> SET
>  select * from pg_namespace where nspname ilike '%schema123%';
>  nspname | nspowner | nspacl
> ---------+----------+--------
> (0 rows)
> 
> Is this new behaviour intentional?

Yes. It was felt the 9.1 behavior was too punishing.  I do not recall the
specifics at the moment but I believe 9.0- and 9.2+ simply ignore the
missing schema while 9.1 has the obnoxious behavior that you see.  Though if
any version other than 9.1 and 9.3 matter you should confirm this for
yourself.

David J.


--
View this message in context: http://postgresql.1045698.n5.nabble.com/set-search-path-command-tp5805807p5805809.html
Sent from the PostgreSQL - admin mailing list archive at Nabble.com.


-- 
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin