Bruce Momjian wrote
> 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.
Error makes more sense if the goal is internal consistency. That goal
should be subservient to backward compatibility. Changing LOCK to warning
is less problematic since the likelihood of current code functioning in such
a way that after upgrade it would begin working differently in the absence
of an error does not seem probable. Basically someone would have be
trapping on the error and conditionally branching their logic.
That said, if this was a day 0 decision I'd likely raise an error.
Weakening LOCK doesn't make sense since it is day 0 behavior. Document the
warning for SET as being weaker than ideal because of backward compatibility
and call it a day (i.e. leave LOCK at error). The documentation, not the
code, then enforces the feeling that such usage is considered wrong without
possibly breaking wrong but working code.
David J.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Suggestion-Issue-warning-when-calling-SET-TRANSACTION-outside-transaction-block-tp5743139p5779006.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
