On Nov 28, 2013, at 5:18 PM, Bruce Momjian wrote:
> On Thu, Nov 28, 2013 at 04:51:14PM -0500, Robert Haas wrote:
>> On Wed, Nov 27, 2013 at 4:44 PM, Bruce Momjian wrote:
Seems broadly reasonable, but I'd use "no other effect" throughout.
>>>
>>> That sounds awkward, e.g.:
>>>
>>> Issui
On Thu, Nov 28, 2013 at 04:51:14PM -0500, Robert Haas wrote:
> On Wed, Nov 27, 2013 at 4:44 PM, Bruce Momjian wrote:
> >> Seems broadly reasonable, but I'd use "no other effect" throughout.
> >
> > That sounds awkward, e.g.:
> >
> > Issuing ROLLBACK outside of a transaction
> > block emi
On Wed, Nov 27, 2013 at 4:44 PM, Bruce Momjian wrote:
>> Seems broadly reasonable, but I'd use "no other effect" throughout.
>
> That sounds awkward, e.g.:
>
> Issuing ROLLBACK outside of a transaction
> block emits a warning but has no other effect.
>
> I could live with this:
>
>
On Wed, Nov 27, 2013 at 04:44:02PM -0500, Bruce Momjian wrote:
> I could live with this:
>
> Issuing ROLLBACK outside of a transaction
> block has no effect except emitting a warning.
Proposed doc patch attached.
--
Bruce Momjian http://momjian.us
EnterpriseDB
On Wed, Nov 27, 2013 at 03:59:31PM -0500, Robert Haas wrote:
> On Tue, Nov 26, 2013 at 5:02 PM, Bruce Momjian wrote:
> > On Tue, Nov 26, 2013 at 01:58:04PM -0300, Alvaro Herrera wrote:
> >> Bruce Momjian escribió:
> >> > On Tue, Nov 26, 2013 at 11:22:39AM -0500, Tom Lane wrote:
> >>
> >> > > > Uh,
On Tue, Nov 26, 2013 at 5:02 PM, Bruce Momjian wrote:
> On Tue, Nov 26, 2013 at 01:58:04PM -0300, Alvaro Herrera wrote:
>> Bruce Momjian escribió:
>> > On Tue, Nov 26, 2013 at 11:22:39AM -0500, Tom Lane wrote:
>>
>> > > > Uh, I ended up mentioning "no effect" to highlight it does nothing,
>> > > >
On Tue, Nov 26, 2013 at 01:58:04PM -0300, Alvaro Herrera wrote:
> Bruce Momjian escribió:
> > On Tue, Nov 26, 2013 at 11:22:39AM -0500, Tom Lane wrote:
>
> > > > Uh, I ended up mentioning "no effect" to highlight it does nothing,
> > > > rather than mention a warning. Would people prefer I say "w
Bruce Momjian escribió:
> On Tue, Nov 26, 2013 at 11:22:39AM -0500, Tom Lane wrote:
> > > Uh, I ended up mentioning "no effect" to highlight it does nothing,
> > > rather than mention a warning. Would people prefer I say "warning"? Or
> > > should I say "issues a warning because it has no effect
On Tue, Nov 26, 2013 at 11:22:39AM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > On Mon, Nov 25, 2013 at 10:04:19PM -0500, Robert Haas wrote:
> >> But the documentation says:
> >>
> >> - Issuing ABORT when not inside a transaction does
> >> - no harm, but it will provoke a warning messag
Bruce Momjian writes:
> On Mon, Nov 25, 2013 at 10:04:19PM -0500, Robert Haas wrote:
>> But the documentation says:
>>
>> - 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.
On Mon, Nov 25, 2013 at 10:12:43PM -0500, Bruce Momjian wrote:
> > Those things are not the same.
>
> Uh, I ended up mentioning "no effect" to highlight it does nothing,
> rather than mention a warning. Would people prefer I say "warning"? Or
> should I say "issues a warning because it has no ef
On Mon, Nov 25, 2013 at 10:04:19PM -0500, Robert Haas wrote:
> On Mon, Nov 25, 2013 at 7:19 PM, Bruce Momjian wrote:
> > On Fri, Nov 22, 2013 at 01:19:55PM -0500, Bruce Momjian wrote:
> >> On Fri, Nov 22, 2013 at 12:17:41PM -0500, Bruce Momjian wrote:
> >> > Good points. I have modified the attac
On Mon, Nov 25, 2013 at 7:19 PM, Bruce Momjian wrote:
> On Fri, Nov 22, 2013 at 01:19:55PM -0500, Bruce Momjian wrote:
>> On Fri, Nov 22, 2013 at 12:17:41PM -0500, Bruce Momjian wrote:
>> > Good points. I have modified the attached patch to do as you suggested.
>>
>> Also, I have read through the
On Fri, Nov 22, 2013 at 01:19:55PM -0500, Bruce Momjian wrote:
> On Fri, Nov 22, 2013 at 12:17:41PM -0500, Bruce Momjian wrote:
> > Good points. I have modified the attached patch to do as you suggested.
>
> Also, I have read through the thread and summarized the positions of the
> posters:
>
>
On Fri, Nov 22, 2013 at 12:17:41PM -0500, Bruce Momjian wrote:
> Good points. I have modified the attached patch to do as you suggested.
Also, I have read through the thread and summarized the positions of the
posters:
9.3 WARNING ERROR
SET
On Fri, Nov 22, 2013 at 10:24:35AM -0300, Alvaro Herrera wrote:
> Bruce Momjian escribió:
>
> > OK, here is a patch which changes ABORT from NOTICE to WARNING, and SET
> > from ERROR (which is new in 9.4) to WARNING.
>
> I don't like that this patch changes RequireTransactionChain() from
> actual
Bruce Momjian escribió:
> OK, here is a patch which changes ABORT from NOTICE to WARNING, and SET
> from ERROR (which is new in 9.4) to WARNING.
I don't like that this patch changes RequireTransactionChain() from
actually requiring one, to a function that maybe requires a transaction
chain, and m
Robert Haas wrote:
> Well, Tom and I are on opposite sides of this, I suppose. I
> prefer ERROR for everything other than the top-level transaction
> commands, and see no benefit from opting for a wishy-washy
> warning.
+1
If the user issued a local command outside of a transaction there
is an
On Wed, Nov 20, 2013 at 04:31:12PM -0500, Robert Haas wrote:
> On Wed, Nov 20, 2013 at 4:19 PM, Bruce Momjian wrote:
> > On Wed, Nov 20, 2013 at 10:16:00AM -0500, Bruce Momjian wrote:
> >> > > The attached patch changes ABORT from NOTICE to WARNING, and documents
> >> > > that all other are errors
On Wed, Nov 20, 2013 at 4:19 PM, Bruce Momjian wrote:
> On Wed, Nov 20, 2013 at 10:16:00AM -0500, Bruce Momjian wrote:
>> > > The attached patch changes ABORT from NOTICE to WARNING, and documents
>> > > that all other are errors. This "top-level" logic idea came from Robert
>> > > Haas, and it h
On Wed, Nov 20, 2013 at 10:16:00AM -0500, Bruce Momjian wrote:
> > > The attached patch changes ABORT from NOTICE to WARNING, and documents
> > > that all other are errors. This "top-level" logic idea came from Robert
> > > Haas, and it has some level of consistency.
> >
> > This patch utterly fa
On Wed, Nov 20, 2013 at 10:04:22AM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > On Tue, Nov 19, 2013 at 10:21:47PM -0500, Tom Lane wrote:
> >> My personal standpoint is that I don't care much whether these messages
> >> are NOTICE or WARNING. What I'm not happy about is promoting cases that
Bruce Momjian writes:
> On Tue, Nov 19, 2013 at 10:21:47PM -0500, Tom Lane wrote:
>> My personal standpoint is that I don't care much whether these messages
>> are NOTICE or WARNING. What I'm not happy about is promoting cases that
>> have been non-error conditions for years into ERRORs.
> I don
On Tue, Nov 19, 2013 at 10:21:47PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > Does anyone know if this C comment justifies why ABORT is a NOTICE and
> > not WARNING?
>
> > /*
> > * The user issued ABORT when not inside a transaction. Issue a
> > * NOT
Bruce Momjian writes:
> Does anyone know if this C comment justifies why ABORT is a NOTICE and
> not WARNING?
> /*
> * The user issued ABORT when not inside a transaction. Issue a
> * NOTICE and go to abort state. The upcoming call to
> * Commit
Andres Freund writes:
> On 2013-11-19 13:09:16 -0500, Bruce Momjian wrote:
>> Because as Tom stated, we already do warnings for other useless
>> transaction commands like BEGIN WORK inside a transaction block:
>
> Which imo is a bad, bad historical accident. I've repeatedly seen this
> hide bugs c
On Tue, Nov 19, 2013 at 01:37:56PM -0500, Bruce Momjian wrote:
> On Tue, Nov 19, 2013 at 01:31:55PM -0500, Bruce Momjian wrote:
> > On Tue, Nov 19, 2013 at 01:20:47PM -0500, Robert Haas wrote:
> > > I think the pattern is and should be different for toplevel
> > > transaction control commands than
On Tue, Nov 19, 2013 at 01:31:55PM -0500, Bruce Momjian wrote:
> On Tue, Nov 19, 2013 at 01:20:47PM -0500, Robert Haas wrote:
> > I think the pattern is and should be different for toplevel
> > transaction control commands than for other things. If you issue a
> > BEGIN, we want it to end up that
On Tue, Nov 19, 2013 at 01:20:47PM -0500, Robert Haas wrote:
> I think the pattern is and should be different for toplevel
> transaction control commands than for other things. If you issue a
> BEGIN, we want it to end up that you're definitely in a transaction at
> that point, and if you issue a
On Tue, Nov 19, 2013 at 1:14 PM, Bruce Momjian wrote:
> On Tue, Nov 19, 2013 at 07:12:32PM +0100, Andres Freund wrote:
>> On 2013-11-19 13:09:16 -0500, Bruce Momjian wrote:
>> > > Why change the historical behaviour for savepoints?
>> >
>> > Because as Tom stated, we already do warnings for other
On 2013-11-19 13:14:34 -0500, Bruce Momjian wrote:
> On Tue, Nov 19, 2013 at 07:12:32PM +0100, Andres Freund wrote:
> > But even if that weren't a concern, the fact that BEGIN does it one way
> > currently doesn't seem very indicative of changing other historical
> > behaviour.
>
> Look at this g
On Tue, Nov 19, 2013 at 07:12:32PM +0100, Andres Freund wrote:
> On 2013-11-19 13:09:16 -0500, Bruce Momjian wrote:
> > > Why change the historical behaviour for savepoints?
> >
> > Because as Tom stated, we already do warnings for other useless
> > transaction commands like BEGIN WORK inside a tr
On 2013-11-19 13:09:16 -0500, Bruce Momjian wrote:
> > Why change the historical behaviour for savepoints?
>
> Because as Tom stated, we already do warnings for other useless
> transaction commands like BEGIN WORK inside a transaction block:
Which imo is a bad, bad historical accident. I've repea
On Tue, Nov 19, 2013 at 1:05 PM, Bruce Momjian wrote:
> A patch to issue only warnings is attached. In a way this change
> improves the code by throwing errors only when the commands are invalid,
> rather than just useless. You could argue that ROLLBACK TO SAVEPOINT
> should throw an error becau
On Tue, Nov 19, 2013 at 07:08:05PM +0100, Andres Freund wrote:
> On 2013-11-19 13:05:01 -0500, Bruce Momjian wrote:
> > SAVEPOINT
>
> > test=> ROLLBACK TO SAVEPOINT asdf;
> > ERROR: ROLLBACK TO SAVEPOINT can only be used in transaction blocks
> >
> > Notice that they do _not_ check t
On 2013-11-19 13:05:01 -0500, Bruce Momjian wrote:
> SAVEPOINT
> test=> ROLLBACK TO SAVEPOINT asdf;
> ERROR: ROLLBACK TO SAVEPOINT can only be used in transaction blocks
>
> Notice that they do _not_ check their arguments; they just throw
> errors. With this patch they issue
On Sat, Nov 9, 2013 at 02:15:52PM -0500, Robert Haas wrote:
> On Fri, Nov 8, 2013 at 5:36 PM, Tom Lane wrote:
> > [ I'm so far behind ... ]
> >
> > Bruce Momjian writes:
> >> Applied. Thank you for all your suggestions.
> >
> > I thought the suggestion had been to issue a *warning*. How did th
On Sat, Nov 9, 2013 at 02:15:52PM -0500, Robert Haas wrote:
> On Fri, Nov 8, 2013 at 5:36 PM, Tom Lane wrote:
> > [ I'm so far behind ... ]
> >
> > Bruce Momjian writes:
> >> Applied. Thank you for all your suggestions.
> >
> > I thought the suggestion had been to issue a *warning*. How did th
On Fri, Nov 8, 2013 at 5:36 PM, Tom Lane wrote:
> [ I'm so far behind ... ]
>
> Bruce Momjian writes:
>> Applied. Thank you for all your suggestions.
>
> I thought the suggestion had been to issue a *warning*. How did that
> become an error? This patch seems likely to break applications that
>
[ I'm so far behind ... ]
Bruce Momjian writes:
> Applied. Thank you for all your suggestions.
I thought the suggestion had been to issue a *warning*. How did that
become an error? This patch seems likely to break applications that
may have just been harmlessly sloppy about when they were iss
On Fri, Oct 4, 2013 at 09:40:38AM +0530, Amit Kapila wrote:
> On Thu, Oct 3, 2013 at 8:35 PM, Andres Freund wrote:
> > On 2013-09-30 22:19:31 -0400, Bruce Momjian wrote:
> >> On Sun, Sep 29, 2013 at 11:40:51AM +0530, Amit Kapila wrote:
> >> > >> Shouldn't we do it for Set Constraints as well?
> >
On Thu, Oct 3, 2013 at 8:32 PM, Bruce Momjian wrote:
> On Thu, Oct 3, 2013 at 11:50:09AM +0530, Amit Kapila wrote:
>> > I looked at this but could not see how to easily pass the value of
>> > 'isTopLevel' down to the SELECT. All the other checks have isTopLevel
>> > passed down from the utility
On Thu, Oct 3, 2013 at 8:35 PM, Andres Freund wrote:
> On 2013-09-30 22:19:31 -0400, Bruce Momjian wrote:
>> On Sun, Sep 29, 2013 at 11:40:51AM +0530, Amit Kapila wrote:
>> > >> Shouldn't we do it for Set Constraints as well?
>> > >
>> > > Oh, very good point. I missed that one. Updated patch at
On 2013-09-30 22:19:31 -0400, Bruce Momjian wrote:
> On Sun, Sep 29, 2013 at 11:40:51AM +0530, Amit Kapila wrote:
> > >> Shouldn't we do it for Set Constraints as well?
> > >
> > > Oh, very good point. I missed that one. Updated patch attached.
>
> I am glad you are seeing things I am not. :-)
On Thu, Oct 3, 2013 at 11:50:09AM +0530, Amit Kapila wrote:
> > I looked at this but could not see how to easily pass the value of
> > 'isTopLevel' down to the SELECT. All the other checks have isTopLevel
> > passed down from the utility case statement.
>
> Yes, we cannot pass isTopLevel, but as
On Tue, Oct 1, 2013 at 7:49 AM, Bruce Momjian wrote:
> On Sun, Sep 29, 2013 at 11:40:51AM +0530, Amit Kapila wrote:
>> >> Shouldn't we do it for Set Constraints as well?
>> >
>> > Oh, very good point. I missed that one. Updated patch attached.
>
> I am glad you are seeing things I am not. :-)
>
On Sun, Sep 29, 2013 at 11:40:51AM +0530, Amit Kapila wrote:
> >> Shouldn't we do it for Set Constraints as well?
> >
> > Oh, very good point. I missed that one. Updated patch attached.
I am glad you are seeing things I am not. :-)
> 1. The function set_config also needs similar functionality,
On Wed, Sep 25, 2013 at 2:55 AM, Bruce Momjian wrote:
> On Thu, Sep 12, 2013 at 09:38:43AM +0530, Amit Kapila wrote:
>> > I have created the attached patch which issues an error when SET
>> > TRANSACTION and SET LOCAL are used outside of transactions:
>> >
>> > test=> set transaction isola
On Thu, Sep 12, 2013 at 09:38:43AM +0530, Amit Kapila wrote:
> > I have created the attached patch which issues an error when SET
> > TRANSACTION and SET LOCAL are used outside of transactions:
> >
> > test=> set transaction isolation level serializable;
> > ERROR: SET TRANSACTION
On Wed, Sep 11, 2013 at 4:19 AM, Bruce Momjian wrote:
> On Sun, Feb 3, 2013 at 07:19:14AM +, Amit kapila wrote:
>>
>> On Saturday, February 02, 2013 9:08 PM Robert Haas wrote:
>> On Fri, Feb 1, 2013 at 12:04 AM, Amit Kapila wrote:
>> >> I think user should be aware of effect before using SET
On Sun, Feb 3, 2013 at 07:19:14AM +, Amit kapila wrote:
>
> On Saturday, February 02, 2013 9:08 PM Robert Haas wrote:
> On Fri, Feb 1, 2013 at 12:04 AM, Amit Kapila wrote:
> >> I think user should be aware of effect before using SET commands, as these
> >> are used at various levels (TRANSA
On Saturday, February 02, 2013 9:08 PM Robert Haas wrote:
On Fri, Feb 1, 2013 at 12:04 AM, Amit Kapila wrote:
>> I think user should be aware of effect before using SET commands, as these
>> are used at various levels (TRANSACTION, SESSION, ...).
> Ideally, sure. But these kinds of mistakes ar
On Fri, Feb 1, 2013 at 12:04 AM, Amit Kapila wrote:
> I think user should be aware of effect before using SET commands, as these
> are used at various levels (TRANSACTION, SESSION, ...).
Ideally, sure. But these kinds of mistakes are easy to make. That's
why LOCK and DECLARE CURSOR already emi
On Wednesday, January 30, 2013 6:53 AM Morten Hustveit wrote:
> Hi!
>
> Calling "SET TRANSACTION ISOLATION LEVEL ..." outside a transaction
> block has no effect. This is unlike "LOCK ..." and "DECLARE foo
> CURSOR FOR ...", which both raise an error. This is also unlike
> MySQL, where such a st
54 matches
Mail list logo
