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
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 |