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.
David J.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Suggestion-Issue-warning-when-calling-SET-TRANSACTION-outside-transaction-block-tp5743139p5778994.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
