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@momjian.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@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +