On Wed, Nov 20, 2013 at 04:31:12PM -0500, Robert Haas wrote: > On Wed, Nov 20, 2013 at 4:19 PM, Bruce Momjian <br...@momjian.us> wrote: > > On Wed, Nov 20, 2013 at 10:16:00AM -0500, Bruce Momjian wrote: > >> > > The attached patch changes ABORT from NOTICE to WARNING, and documents > >> > > that all other are errors. This "top-level" logic idea came from > >> > > Robert > >> > > Haas, and it has some level of consistency. > >> > > >> > This patch utterly fails to address my complaint. > >> > > >> > More to the point, I think it's a waste of time to make these sorts of > >> > adjustments. The only thanks you're likely to get for it is complaints > >> > about cross-version behavioral changes. Also, you're totally ignoring > >> > the thought that these different message levels might've been selected > >> > intentionally, back when the code was written. Since there have been > >> > no field complaints about the inconsistency, what's your hurry to > >> > change it? See Emerson. > >> > >> My problem was that they issued _no_ message at all. I am fine with > >> them issuing a warning if that's what people prefer. As they are all > >> SET commands, they will be consistent. > > > > OK, here is a patch which changes ABORT from NOTICE to WARNING, and SET > > from ERROR (which is new in 9.4) to WARNING. > > Well, Tom and I are on opposite sides of this, I suppose. I prefer > ERROR for everything other than the top-level transaction commands, > and see no benefit from opting for a wishy-washy warning.
Well, the only way I can process this is to think of psql with ON_ERROR_STOP enabled. Would we want a no-op command to abort psql? I can see logic that top-level transaction commands and SET to not, but other commands do. I can also see them all aborting psql, or none of them. :-( -- 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
