On Fri, Nov 29, 2013 at 01:19:54PM -0500, Bruce Momjian wrote:
> On Fri, Nov 29, 2013 at 01:05:20PM -0500, Bruce Momjian wrote:
> > On Fri, Nov 29, 2013 at 12:27:49AM -0500, Robert Haas wrote:
> > > On Thu, Nov 28, 2013 at 11:04 PM, Alvaro Herrera
> > > wrote:
> > > > David Johnston wrote:
> > > >
On Fri, Nov 29, 2013 at 01:05:20PM -0500, Bruce Momjian wrote:
> On Fri, Nov 29, 2013 at 12:27:49AM -0500, Robert Haas wrote:
> > On Thu, Nov 28, 2013 at 11:04 PM, Alvaro Herrera
> > wrote:
> > > David Johnston wrote:
> > >
> > >> In all of these cases we are assuming that the user understands tha
On Fri, Nov 29, 2013 at 12:27:49AM -0500, Robert Haas wrote:
> On Thu, Nov 28, 2013 at 11:04 PM, Alvaro Herrera
> wrote:
> > David Johnston wrote:
> >
> >> In all of these cases we are assuming that the user understands that
> >> emitting a warning means that something is being logged to disk and
On Fri, Nov 29, 2013 at 12:27:49AM -0500, Robert Haas wrote:
> I wish we'd just left this whole thing well enough alone. It wasn't
> broken, and didn't need fixing.
Well, this started with a complaint that one SET command outside of a
transaction had no effect, and expanded to other SET commands
On Thu, Nov 28, 2013 at 11:04 PM, Alvaro Herrera
wrote:
> David Johnston wrote:
>
>> In all of these cases we are assuming that the user understands that
>> emitting a warning means that something is being logged to disk and thus is
>> causing a resource drain.
>>
>> I like explicitly saying that
David Johnston wrote:
> In all of these cases we are assuming that the user understands that
> emitting a warning means that something is being logged to disk and thus is
> causing a resource drain.
>
> I like explicitly saying that issuing these commands is pointless/"has no
> effect"; being ind
Robert Haas wrote
>>
>> Issuing
>
> ROLLBACK
>
> outside of a transaction
>> block has the sole effect of emitting a warning.
>
> Sure, that sounds OK.
>
> ...Robert
+1 for:
Issuing ROLLBACK outside of a transaction
block has no effect except emitting a warning.
In all of these
On Tue, Nov 26, 2013 at 08:54:13AM -0800, David Johnston wrote:
> How about:
>
> "Issuing outside of a transaction has no effect and will provoke a
> warning."
>
> I dislike "does no harm" because it can if someone thinks the current state
> is different than reality.
>
> It is good to indicate
Bruce Momjian wrote
>> >> - Issuing
>
> ABORT
>
> when not inside a transaction does
>> >> - no harm, but it will provoke a warning message.
>> >> + Issuing
>
> ABORT
>
> outside of a transaction block has no effect.
>> >>
>> >> Those things are not the same.
>>
>> > Uh, I ended up
Tom Lane-2 wrote
> David Johnston <
> polobo@
> > writes:
>> Robert Haas wrote
>>> I don't think it's worth breaking backward compatibility. I'm not
>>> entirely sure what I would have decided here in a vacuum, but at this
>>> point existing precedent seems determinative.
>
>> Well, at this poi
On Tue, Nov 19, 2013 at 12:24:50PM -0500, Tom Lane wrote:
> David Johnston writes:
> > Robert Haas wrote
> >> I don't think it's worth breaking backward compatibility. I'm not
> >> entirely sure what I would have decided here in a vacuum, but at this
> >> point existing precedent seems determinat
David Johnston writes:
> Robert Haas wrote
>> I don't think it's worth breaking backward compatibility. I'm not
>> entirely sure what I would have decided here in a vacuum, but at this
>> point existing precedent seems determinative.
> Well, at this point we have already broken backward compatib
On Tue, Nov 19, 2013 at 11:53 AM, David Johnston wrote:
> Well, at this point we have already broken backward compatibility by
> releasing this. With Tom's thread necromancy I missed the fact this got
> released in 9.3
Eh, really? I don't see it in 9.3.
--
Robert Haas
EnterpriseDB: http://www
Robert Haas wrote
> On Mon, Nov 18, 2013 at 9:07 PM, Bruce Momjian <
> bruce@
> > wrote:
>> Well, ERROR is what LOCK returns, so if we change SET TRANSACTION to be
>> WARNING, we should change LOCK too, so on backward-compatibility
>> grounds, ERROR makes more sense.
>>
>> Personally, I am fine w
On Mon, Nov 18, 2013 at 9:07 PM, Bruce Momjian wrote:
> Well, ERROR is what LOCK returns, so if we change SET TRANSACTION to be
> WARNING, we should change LOCK too, so on backward-compatibility
> grounds, ERROR makes more sense.
>
> Personally, I am fine with changing them all to WARNING.
I don'
Bruce Momjian wrote
> On Mon, Nov 18, 2013 at 06:30:32PM -0800, David Johnston wrote:
>> > Personally, I am fine with changing them all to WARNING.
>>
>> Error makes more sense if the goal is internal consistency. That goal
>> should be subservient to backward compatibility. Changing LOCK to
>>
On Mon, Nov 18, 2013 at 06:30:32PM -0800, David Johnston wrote:
> > Personally, I am fine with changing them all to WARNING.
>
> Error makes more sense if the goal is internal consistency. That goal
> should be subservient to backward compatibility. Changing LOCK to warning
> is less problematic
Bruce Momjian wrote
> On Mon, Nov 18, 2013 at 05:05:45PM -0800, David Johnston wrote:
>> Bruce Momjian wrote
>> > Considering we are doing this outside of a transaction, and WARNING or
>> > ERROR is pretty much the same, from a behavioral perspective.
>> >
>> > Should we change this and LOCK to be
On Mon, Nov 18, 2013 at 05:05:45PM -0800, David Johnston wrote:
> Bruce Momjian wrote
> > Considering we are doing this outside of a transaction, and WARNING or
> > ERROR is pretty much the same, from a behavioral perspective.
> >
> > Should we change this and LOCK to be a warning?
>
> >From the
Bruce Momjian wrote
> Considering we are doing this outside of a transaction, and WARNING or
> ERROR is pretty much the same, from a behavioral perspective.
>
> Should we change this and LOCK to be a warning?
>From the calling application's perspective an error and a warning are
definitely behavi
20 matches
Mail list logo
