Re: invalid search_path complaints

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Scott Mead <scottm(at)openscg(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: invalid search_path complaints
Date: 2012-04-05 00:53:04
Message-ID: CA+Tgmob5Z8r-mm96aku3CSBtr+1MwwXX=HgVwNwU3eWR=CzLKw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Apr 4, 2012 at 12:47 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Now, Scott's comment seems to me to offer a principled way out of this:
> if we define the intended semantics of search_path as being similar
> to the traditional understanding of Unix PATH, then it's not an error
> or even unexpected to have references to nonexistent schemas in there.
> But as soon as you say "I want warnings in some cases", I think we have
> a mess that nobody is ever going to be happy with, because there will
> never be a clear and correct definition of which cases should get
> warnings.

I'm not sure I'm ready to sign on the dotted line with respect to
every aspect of your argument here, but that definition seems OK to
me. In practice it's likely that a lot of the NOTICEs we emit now
will only be seen when restoring dumps, and certainly in that case
it's just junk anyway. So I think this would be fine.

> In any case, I think we might be converging on an agreement that the
> setting should be *applied* if syntactically correct, whether or not
> we are agreed about producing a NOTICE or WARNING for unknown schemas.
> If I have not lost track, that is what happened before 9.1 but is not
> what is happening now, and we should change it to fix that compatibility
> break, independently of the question about messaging.

Sounds that way.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Harold Giménez 2012-04-05 02:26:58 pg_upgrade improvements
Previous Message Kyotaro HORIGUCHI 2012-04-05 00:28:58 Re: Speed dblink using alternate libpq tuple storage