On Mon, Nov 18, 2013 at 05:05:45PM -0800, David Johnston wrote: > Bruce Momjian wrote > > Considering we are doing this outside of a transaction, and WARNING or > > ERROR is pretty much the same, from a behavioral perspective. > > > > Should we change this and LOCK to be a warning? > > >From the calling application's perspective an error and a warning are > definitely behaviorally different. > > For this I'd vote for a warning (haven't pondered the LOCK scenario) as > using SET out of context means the user has a fairly serious > mis-understanding of the code path they have written (accedentially or > otherwise). Notice makes sense (speaking generally and without much > research here) for stuff where the ultimate outcome matches the statement > but the statement itself didn't actually do anything. Auto-sequence and > index generation fell into this but even notice was too noisy. In this case > we'd expect that the no-op statement was issued in error and thus should be > changed making a warning the level of incorrect-ness to communicate. A > notice would be more appropriate if there were valid use-cases for the user > doing this and we just want to make sure they are conscious of the > unusualness of the situation. > > I dislike error for backward compatibility reasons. And saving the user > from this kind of mistake doesn't warrant breaking what could be properly > functioning code. Just because PostgreSQL isn't in a transaction does not > mean the client is expecting the current code to work correctly - even if by > accident - as part of a sequence of queries.
Well, ERROR is what LOCK returns, so if we change SET TRANSACTION to be WARNING, we should change LOCK too, so on backward-compatibility grounds, ERROR makes more sense. Personally, I am fine with changing them all to WARNING. -- 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