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.
