On Thu, Mar 10, 2016 at 10:49 PM, Joel Jacobson <j...@trustly.com> wrote: > On Fri, Mar 11, 2016 at 9:36 AM, Robert Haas <robertmh...@gmail.com> wrote: >> Well, this was discussed. If we keep the Boolean "waiting" column, then >> either: > > Oh, sorry for missing out on that discussion. > >> 1. We make it true only for heavyweight lock waits, and false for >> other kinds of waits. That's pretty strange. >> 2. We make it true for all kinds of waits that we now know how to >> report. That still breaks compatibility. > > Why not 3: We make it true for exactly the same type of situations as > in previous versions. Or is it not possible to do so for some reason?
3 = 1. > Off topic, but related to the backward-compatibility subject: > > Is there any written policy/wiki/thread/document on the topic "When > breaking backward-compatibility is acceptable"? Not to my knowledge. We end up hashing it out on a case-by-case basis. > It would be helpful to get a better understand of this, as some ideas > on how to improve things can quickly be ruled out or ruled in > depending on what is acceptable or not. > For instance, there are some minor but annoying flaws in PL/pgSQL that > I would love to get fixed, > but the main arguments against doing so have been that it might break > some users' code somewhere, > even though doing so would probably be a good thing as the user could > have a bug in the code. > See: https://wiki.postgresql.org/wiki/Improving_PL/PgSQL_(September_2014) I think that with respect to this particular set of improvements, the problem is basically that there are just a lot of things that you could hypothetically change, and it's not altogether clear which ones of those individually would please more people than they displeased, and it's not clear how much change we want to allow in total for the sake of preserving backward compatibility, and then, too, the designs for a lot of the individual features are fertile ground for bikeshedding. I'm not direly opposed to most of what's on that page, but I'm not excited about most of it, either. I bet if we canvassed 10 different companies that made heavy use of PL/pgsql they'd all have a list of proposed changes like that, and I bet some of them would conflict with each other, and I bet if we did all that stuff the average PL/pgsql user's life would not be much better, but the manual would be much longer. (Also, I bet the variable assignments thing would break large amounts of code that is working as designed.) > I think one general rule should be "Breaking backward-compatibility is > acceptable if the new major pg-version throws an error in a situation > where the old major pg-version would conceal a bug or allow misuse of > a feature". > Trying to select the now removed "waiting" column throws an error. > Good! That lead me as a user here to figure out why I can't and > shouldn't use it. :) Yes, I think we use this rubric quite often, and I agree it's a good one. > Trying to e.g. select a different number of columns into a different > number of variables in a PL/pgSQL function doesn't throw an error. > Bad. :( Yeah, I'm sympathetic to that request. That seems like poor error checking and nothing else. (But note that I do not rule here.) -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
