Thread: Re: [BUGS] BUG #1118: Misleading Commit message
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Do we change tags in any other commands?
MOVE, FETCH, EXECUTE ...
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Do we change tags in any other commands? > > MOVE, FETCH, EXECUTE ... Ah, yes, I remember we changed EXECUTE recently to return the tag of what we executed. How do we modify MOVE/FETCH tags? I can't remember. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> MOVE, FETCH, EXECUTE ...
> Ah, yes, I remember we changed EXECUTE recently to return the tag of
> what we executed. How do we modify MOVE/FETCH tags? I can't remember.
I was just looking to see what cases ProcessUtility allowed to change
the tag. I think that what the code does is just to append the row
count, which you could argue isn't "changing the tag". But really,
is returning "UPDATE 0" vs "UPDATE 1" any different conceptually from
what we are talking about here? It's still using the tag to pass back
info about what the command actually did.
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Tom Lane wrote: > >> MOVE, FETCH, EXECUTE ... > > > Ah, yes, I remember we changed EXECUTE recently to return the tag of > > what we executed. How do we modify MOVE/FETCH tags? I can't remember. > > I was just looking to see what cases ProcessUtility allowed to change > the tag. I think that what the code does is just to append the row > count, which you could argue isn't "changing the tag". But really, > is returning "UPDATE 0" vs "UPDATE 1" any different conceptually from > what we are talking about here? It's still using the tag to pass back > info about what the command actually did. Yes, the count is what I remember changing, and as I remember the goal was to have us return MOVE 0 if you do MOVE 1 at the end of a cursor. We already return counts for INSERT/UPDATE/DELETE, but the racial issue with MOVE was that the count returned might not match the count supplied. Therefore, I don't see MOVE/FETCH as the same issue as ROLLBACK. EXECUTE is closer, and I think new for 7.5, but the interesting part there is that you should always get back something different from EXECUTE, while with COMMIT it would change only when you have an aborted transaction. As I remember, the big issue was how often applications are looking and comparing these tags to take actions. I think we should return ROLLBACK on COMMIT failure and we can see if we get any problem reports during beta. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> As I remember, the big issue was how often applications are looking and
> comparing these tags to take actions. I think we should return ROLLBACK
> on COMMIT failure and we can see if we get any problem reports during
> beta.
Good enough; I'll make it happen.
regards, tom lane
FYI: I'm agreeing w/Tom who is agreeing with me. The tag change should be good. I do hope people are not relying on seeing COMMIT when the transaction rolled back. It does not seem that in this case they would. elein On Sat, Jul 10, 2004 at 04:13:49PM -0400, Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > As I remember, the big issue was how often applications are looking and > > comparing these tags to take actions. I think we should return ROLLBACK > > on COMMIT failure and we can see if we get any problem reports during > > beta. > > Good enough; I'll make it happen. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org
elein wrote: > FYI: I'm agreeing w/Tom who is agreeing with me. > > The tag change should be good. I do hope people are > not relying on seeing COMMIT when the transaction > rolled back. It does not seem that in this case > they would. If it is a problem, hopefully we will hear about it during beta. I will mention is as a backward-compatibility issue in the release notes. --------------------------------------------------------------------------- > > elein > > On Sat, Jul 10, 2004 at 04:13:49PM -0400, Tom Lane wrote: > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > > As I remember, the big issue was how often applications are looking and > > > comparing these tags to take actions. I think we should return ROLLBACK > > > on COMMIT failure and we can see if we get any problem reports during > > > beta. > > > > Good enough; I'll make it happen. > > > > regards, tom lane > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 6: Have you searched our list archives? > > > > http://archives.postgresql.org > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian wrote: > elein wrote: > >>FYI: I'm agreeing w/Tom who is agreeing with me. >> >>The tag change should be good. I do hope people are >>not relying on seeing COMMIT when the transaction >>rolled back. It does not seem that in this case >>they would. > > > If it is a problem, hopefully we will hear about it during beta. I will > mention is as a backward-compatibility issue in the release notes. The JDBC driver when talking the V2 protocol (unusual for a recent server, but possible) looks for either COMMIT or ROLLBACK when looking for end-of-transaction, so it should be fine. -O