Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WrbST-0000Rp-4P for pgsql-admin@arkaria.postgresql.org; Mon, 02 Jun 2014 23:16:01 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1WrbSR-00036c-J1 for pgsql-admin@arkaria.postgresql.org; Mon, 02 Jun 2014 23:15:59 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1WrbSQ-00035i-Ha for pgsql-admin@postgresql.org; Mon, 02 Jun 2014 23:15:58 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1WrbSM-0003TC-AP for pgsql-admin@postgresql.org; Mon, 02 Jun 2014 23:15:56 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id s52NFpvm025657; Mon, 2 Jun 2014 19:15:51 -0400 From: Tom Lane To: David G Johnston cc: pgsql-admin@postgresql.org Subject: Re: set search_path command In-reply-to: <1401746452731-5805809.post@n5.nabble.com> References: <1401746452731-5805809.post@n5.nabble.com> Comments: In-reply-to David G Johnston message dated "Mon, 02 Jun 2014 15:00:53 -0700" Date: Mon, 02 Jun 2014 19:15:51 -0400 Message-ID: <25656.1401750951@sss.pgh.pa.us> X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-admin Precedence: bulk Sender: pgsql-admin-owner@postgresql.org David G Johnston writes: > Radovan Jablonovsky wrote >> 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. A quick check says that an interactive "SET search_path = nosuchschema" command fails in previous versions as well as 9.1. However, I believe that noninteractive settings (eg, from postgresql.conf or ALTER DATABASE SET) have always accepted paths including nonexistent schemas. This was felt to be inconsistent; and also, IIRC, in 9.1 or 9.2 we had made some code refactorings that made it difficult to sustain such inconsistent behavior. So we decided to go for the laxer behavior in all cases rather than the stricter behavior in all cases. Another rationale for this change was the analogy between search_path and Unix PATH settings. AFAIK, no Unix-oid platform anywhere will complain if your PATH mentions a nonexistent directory. regards, tom lane -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin