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
alvhe...@2ndquadrant.com wrote:
David Johnston
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 Fri, Nov 29, 2013 at 12:27:49AM -0500, Robert Haas wrote:
On Thu, Nov 28, 2013 at 11:04 PM, Alvaro Herrera
alvhe...@2ndquadrant.com 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
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
alvhe...@2ndquadrant.com wrote:
David Johnston wrote:
In all of these cases we are assuming that the user
Robert Haas wrote
Issuing
command
ROLLBACK
/
outside of a transaction
block has the sole effect of emitting a warning.
Sure, that sounds OK.
...Robert
+1 for:
Issuing commandROLLBACK/ outside of a transaction
block has no effect except emitting a warning.
In all of
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 indirect
On Thu, Nov 28, 2013 at 11:04 PM, Alvaro Herrera
alvhe...@2ndquadrant.com 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
Bruce Momjian wrote
- Issuing
command
ABORT
/
when not inside a transaction does
- no harm, but it will provoke a warning message.
+ Issuing
command
ABORT
/
outside of a transaction block has no effect.
Those things are not the same.
Uh, I ended up mentioning no
On Tue, Nov 26, 2013 at 08:54:13AM -0800, David Johnston wrote:
How about:
Issuing command 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 that
On Mon, Nov 18, 2013 at 9:07 PM, Bruce Momjian br...@momjian.us 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
Robert Haas wrote
On Mon, Nov 18, 2013 at 9:07 PM, Bruce Momjian lt;
bruce@
gt; 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
On Tue, Nov 19, 2013 at 11:53 AM, David Johnston pol...@yahoo.com 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
David Johnston pol...@yahoo.com 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
On Tue, Nov 19, 2013 at 12:24:50PM -0500, Tom Lane wrote:
David Johnston pol...@yahoo.com 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
Tom Lane-2 wrote
David Johnston lt;
polobo@
gt; 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
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
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 calling
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 a warning?
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 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
20 matches
Mail list logo
