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

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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +