Re: Tom Lane 2012-04-04 28647.1333558...@sss.pgh.pa.us
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
Christoph Berg c...@df7cb.de writes:
Re: Tom Lane 2012-04-04 28647.1333558...@sss.pgh.pa.us
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
On Tue, Apr 10, 2012 at 5:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Christoph Berg c...@df7cb.de writes:
Re: Tom Lane 2012-04-04 28647.1333558...@sss.pgh.pa.us
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
Robert Haas robertmh...@gmail.com writes:
On Tue, Apr 10, 2012 at 5:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I am not sure whether we should consider back-patching this into 9.1,
although that would be necessary if we wanted to fix Robert's original
complaint against 9.1. Thoughts?
I guess
On Tue, Apr 10, 2012 at 7:14 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Apr 10, 2012 at 5:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I am not sure whether we should consider back-patching this into 9.1,
although that would be necessary if we wanted
Robert Haas robertmh...@gmail.com writes:
On Tue, Apr 10, 2012 at 7:14 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Anyway, if you're happy with 9.1 being an outlier on this behavior,
I won't press the point.
I'm not, particularly.
Well, the other thing we could do is tweak the rules for when to
On Tue, Apr 10, 2012 at 9:37 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Apr 10, 2012 at 7:14 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Anyway, if you're happy with 9.1 being an outlier on this behavior,
I won't press the point.
I'm not,
Robert Haas robertmh...@gmail.com writes:
On Tue, Apr 10, 2012 at 9:37 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, the other thing we could do is tweak the rules for when to print a
complaint. I notice that in check_temp_tablespaces we use the rule
source == PGC_S_SESSION (ie, SET)
Scott Mead sco...@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
On Wed, Apr 4, 2012 at 12:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Scott Mead sco...@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
Scott Mead sco...@openscg.com writes:
On Wed, Apr 4, 2012 at 12:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
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
On Wed, Apr 4, 2012 at 12:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Scott Mead sco...@openscg.com writes:
On Wed, Apr 4, 2012 at 12:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, that's an interesting analogy. Are you arguing that we should
always accept any syntactically-valid search_path
Robert Haas robertmh...@gmail.com writes:
On Wed, Apr 4, 2012 at 12:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
You're getting squishy on me ...
My feeling on this is that it's OK to warn if the search_path is set
to something that's not valid, and it might also be OK to not warn.
Right now we
On Wed, Apr 4, 2012 at 12:47 PM, Tom Lane t...@sss.pgh.pa.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
Robert Haas robertmh...@gmail.com writes:
If you use ALTER ROLE/DATABASE SET to configure an invalid
search_path, PostgreSQL 9.1 issues a complaint about the invalid
setting on each new connection. This is a behavior change relatively
to previous releases, which did not.
I would say that's
On Tue, Apr 3, 2012 at 11:49 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
If you use ALTER ROLE/DATABASE SET to configure an invalid
search_path, PostgreSQL 9.1 issues a complaint about the invalid
setting on each new connection. This is a behavior change
On Tue, Apr 3, 2012 at 12:05 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Apr 3, 2012 at 11:49 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
If you use ALTER ROLE/DATABASE SET to configure an invalid
search_path, PostgreSQL 9.1 issues a complaint
Robert Haas robertmh...@gmail.com writes:
On Tue, Apr 3, 2012 at 12:05 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Apr 3, 2012 at 11:49 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I would say that's an improvement. Do you think it isn't?
It seems like a log spam hazard at high connection
On 3 April 2012 19:16, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Apr 3, 2012 at 12:05 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Apr 3, 2012 at 11:49 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I would say that's an improvement. Do you think it
On Tue, Apr 3, 2012 at 2:16 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Apr 3, 2012 at 12:05 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Apr 3, 2012 at 11:49 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I would say that's an improvement. Do you
Robert Haas robertmh...@gmail.com writes:
So we have an established precedent that it is right to warn about
things that are sketchy at the time that they are defined, but not
every time they are used.
Sure, but we don't have that option available to us here --- or more
accurately, ALTER
On Tue, Apr 3, 2012 at 2:37 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
So we have an established precedent that it is right to warn about
things that are sketchy at the time that they are defined, but not
every time they are used.
Sure, but we don't
22 matches
Mail list logo
