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

On Wed, Nov 20, 2013 at 04:31:12PM -0500, Robert Haas wrote:
> On Wed, Nov 20, 2013 at 4:19 PM, Bruce Momjian <bruce(at)momjian(dot)us> 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 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.
> >>
> >> My problem was that they issued _no_ message at all. I am fine with
> >> them issuing a warning if that's what people prefer. As they are all
> >> SET commands, they will be consistent.
> >
> > OK, here is a patch which changes ABORT from NOTICE to WARNING, and SET
> > from ERROR (which is new in 9.4) to WARNING.
>
> 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.

Well, the only way I can process this is to think of psql with
ON_ERROR_STOP enabled. Would we want a no-op command to abort psql? I
can see logic that top-level transaction commands and SET to not, but
other commands do. I can also see them all aborting psql, or none of
them. :-(

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +