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.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ Everyone has their own god. +
