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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
