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

Bruce Momjian wrote
> On Mon, Nov 18, 2013 at 06:30:32PM -0800, David Johnston wrote:
>> > 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.
> 
> We normally don't approach warts with documentation --- we usually just
> fix them and document them in the release notes.  If we did, our docs
> would be a whole lot uglier.

That is a fair point - though it may be that this instance needs to be one
of those "usually" exceptions.

For any sane use-case turning this into an error shouldn't cause any grief;
and those cases where there is grief should be evaluated and changed anyway.

I could honestly live with either change to "SET TRANSACTION" but regardless
would leave "LOCK" as-is.  The backward compatibility concern, while valid,
does indeed seem weak and worth breaking in order to maintain a consistent
ABI going forward.

David J.




--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Suggestion-Issue-warning-when-calling-SET-TRANSACTION-outside-transaction-block-tp5743139p5779028.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.