Re: Suggestion: Issue warning when calling SET TRANSACTION outside transaction block

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Morten Hustveit <morten(at)eventures(dot)vc>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Suggestion: Issue warning when calling SET TRANSACTION outside transaction block
Date: 2013-11-20 15:04:22
Message-ID: 11821.1384959862@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <bruce(at)momjian(dot)us> 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't remember any cases where that was suggested.

Apparently you've forgotten the commit that was the subject of this
thread. You took a bunch of SET cases that we've always accepted
without any complaint whatsoever, and made them into ERRORs, thereby
breaking any applications that might've expected such usage to be
harmless. I would be okay if that patch had issued WARNINGs, which
as you can see from the thread title was the original suggestion.

> 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 fails to address my complaint.

More to the point, I think it's a waste of time to make these sorts of
adjustments. The only thanks you're likely to get for it is complaints
about cross-version behavioral changes. Also, you're totally ignoring
the thought that these different message levels might've been selected
intentionally, back when the code was written. Since there have been
no field complaints about the inconsistency, what's your hurry to
change it? See Emerson.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2013-11-20 15:06:04 Re: Data corruption issues using streaming replication on 9.0.14/9.2.5/9.3.1
Previous Message Andres Freund 2013-11-20 14:58:58 Re: Autoconf 2.69 update