Robert Haas writes:
> On Tue, Apr 10, 2012 at 9:37 PM, Tom Lane 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) -> error
>>source == PG
On Tue, Apr 10, 2012 at 9:37 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Apr 10, 2012 at 7:14 PM, Tom Lane 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 twe
Robert Haas writes:
> On Tue, Apr 10, 2012 at 7:14 PM, Tom Lane 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 print a
complaint. I notice that i
On Tue, Apr 10, 2012 at 7:14 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Apr 10, 2012 at 5:20 PM, Tom Lane 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.
Robert Haas writes:
> On Tue, Apr 10, 2012 at 5:20 PM, Tom Lane 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 my feeling would be "no", becau
On Tue, Apr 10, 2012 at 5:20 PM, Tom Lane wrote:
> Christoph Berg 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 trad
Christoph Berg 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 an err
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 ha
On Wed, Apr 4, 2012 at 12:47 PM, Tom Lane 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 refe
Robert Haas writes:
> On Wed, Apr 4, 2012 at 12:22 PM, Tom Lane 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 emit a NOTICE and I don't feel te
On Wed, Apr 4, 2012 at 12:22 PM, Tom Lane wrote:
> Scott Mead writes:
>> On Wed, Apr 4, 2012 at 12:02 PM, Tom Lane 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 sc
Scott Mead writes:
> On Wed, Apr 4, 2012 at 12:02 PM, Tom Lane 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 be hard to do that.
>I th
On Wed, Apr 4, 2012 at 12:02 PM, Tom Lane wrote:
> Scott Mead 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 goi
Scott Mead 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
On Tue, Apr 3, 2012 at 2:37 PM, Tom Lane wrote:
> Robert Haas 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 u
Robert Haas 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 USER/DATABASE SET *does*
On Tue, Apr 3, 2012 at 2:16 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Apr 3, 2012 at 12:05 PM, Robert Haas wrote:
>>> On Tue, Apr 3, 2012 at 11:49 AM, Tom Lane wrote:
I would say that's an improvement. Do you think it isn't?
>
>>> It seems like a log spam hazard at high connect
On 3 April 2012 19:16, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Apr 3, 2012 at 12:05 PM, Robert Haas wrote:
>>> On Tue, Apr 3, 2012 at 11:49 AM, Tom Lane wrote:
I would say that's an improvement. Do you think it isn't?
>
>>> It seems like a log spam hazard at high connection rates
Robert Haas writes:
> On Tue, Apr 3, 2012 at 12:05 PM, Robert Haas wrote:
>> On Tue, Apr 3, 2012 at 11:49 AM, Tom Lane wrote:
>>> I would say that's an improvement. Do you think it isn't?
>> It seems like a log spam hazard at high connection rates.
[ shrug... ] Failing to report a problem is
On Tue, Apr 3, 2012 at 12:05 PM, Robert Haas wrote:
> On Tue, Apr 3, 2012 at 11:49 AM, Tom Lane wrote:
>> Robert Haas 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. T
On Tue, Apr 3, 2012 at 11:49 AM, Tom Lane wrote:
> Robert Haas 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
Robert Haas 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 an improvement. Do
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. git bisect blames this commit:
2594cf0e8c0440619b1651c5a406d37
23 matches
Mail list logo
