Re: invalid search_path complaints - Mailing list pgsql-hackers

From Scott Mead
Subject Re: invalid search_path complaints
Date
Msg-id CAKq0gv+WuamOJih1UdxmxfuUeV91h-aWTDeRXwMFUH8BtYMaqQ@mail.gmail.com
Whole thread Raw
In response to Re: invalid search_path complaints  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: invalid search_path complaints  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

On Wed, Apr 4, 2012 at 12:02 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Scott Mead <scottm@openscg.com> writes:
> Personally, I feel that if unix will let you be stupid:
>     $ export PATH=/usr/bin:/this/invalid/crazy/path
>     $ echo $PATH
>     /usr/bin:/this/invalid/crazy/path
> PG should trust that I'll get where I'm going eventually :)

Well, that's an interesting analogy.  Are you arguing that we should
always accept any syntactically-valid search_path setting, no matter
whether the mentioned schemas exist?  It wouldn't be hard to do that.

   I think we should always accept a syntactically valid search_path.
 
The fun stuff comes in when you try to say "I want a warning in these
contexts but not those", because (a) the behavior you think you want
turns out to be pretty squishy, and (b) it's not always clear from the
implementation level what the context is.

ISTM that just issuing a warning whenever you set the search_path (no matter which context) feels valid (and better than the above *nix behavior).  I would personally be opposed to seeing it on login however.

--Scott

 

                       regards, tom lane

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: invalid search_path complaints
Next
From: Tom Lane
Date:
Subject: Re: log chunking broken with large queries under load