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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
