Re: Re: Suggestion: Issue warning when calling SET TRANSACTION outside transaction block - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Re: Suggestion: Issue warning when calling SET TRANSACTION outside transaction block
Date
Msg-id 20131119020713.GG28149@momjian.us
Whole thread Raw
In response to Re: Suggestion: Issue warning when calling SET TRANSACTION outside transaction block  (David Johnston <polobo@yahoo.com>)
Responses Re: Suggestion: Issue warning when calling SET TRANSACTION outside transaction block
Re: Re: Suggestion: Issue warning when calling SET TRANSACTION outside transaction block
List pgsql-hackers
On Mon, Nov 18, 2013 at 05:05:45PM -0800, David Johnston wrote:
> Bruce Momjian wrote
> > Considering we are doing this outside of a transaction, and WARNING or
> > ERROR is pretty much the same, from a behavioral perspective.
> > 
> > Should we change this and LOCK to be a warning?
> 
> >From the calling application's perspective an error and a warning are
> definitely behaviorally different.
> 
> For this I'd vote for a warning (haven't pondered the LOCK scenario) as
> using SET out of context means the user has a fairly serious
> mis-understanding of the code path they have written (accedentially or
> otherwise).  Notice makes sense (speaking generally and without much
> research here) for stuff where the ultimate outcome matches the statement
> but the statement itself didn't actually do anything.  Auto-sequence and
> index generation fell into this but even notice was too noisy.  In this case
> we'd expect that the no-op statement was issued in error and thus should be
> changed making a warning the level of incorrect-ness to communicate.  A
> notice would be more appropriate if there were valid use-cases for the user
> doing this and we just want to make sure they are conscious of the
> unusualness of the situation.
> 
> I dislike error for backward compatibility reasons.  And saving the user
> from this kind of mistake doesn't warrant breaking what could be properly
> functioning code.  Just because PostgreSQL isn't in a transaction does not
> mean the client is expecting the current code to work correctly - even if by
> accident - as part of a sequence of queries.

Well, ERROR is what LOCK returns, so if we change SET TRANSACTION to be
WARNING, we should change LOCK too, so on backward-compatibility
grounds, ERROR makes more sense.

Personally, I am fine with changing them all to WARNING.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +



pgsql-hackers by date:

Previous
From: KONDO Mitsumasa
Date:
Subject: Re: Improvement of pg_stat_statement usage about buffer hit ratio
Next
From: Michael Paquier
Date:
Subject: Re: [PATCH] configure: allow adding a custom string to PG_VERSION