On Thu, Jan 5, 2017 at 11:03 AM, Robert Haas <robertmh...@gmail.com> wrote: > Now, that's not to say we should never break backward compatibility. > Sometimes we should. I think the problem with PL/pgsql is that many > of the compatibility breaks that people want are likely to lead to > subtle misbehavior rather than outright failure, or are not easy to > spot via a cursory look ("hmm, could that SELECT query ever return > more than one row?").
The core issue is that developers tend to be very poor at estimating the impacts of changes; they look at things the the lens of the "new". Professional software development is quite expensive and framework- (I'll lump the database and it's various built-in features under that term) level changes are essentially throwing out some portion of our user's investments. Even fairly innocent compatibility breaks can have major downstream impacts on our users and it's always much worse than expected. For example, nobody thought that changing the bytea text encoding format to hex would have corrupted our user's data, but it did. TBH, the discussion should shift away from specific issues on compatibility and towards a specific set of standards and policies around how to do it and what kinds of technical justifications need to be made in advance. Security problems for example could be argued as a valid reason to break user code, or poor adherence to the the SQL standard which are in turn blocking other content. Minus those kinds of considerations it's really just not worth doing, and there's no tricky strategy like playing with version numbers that can game that rule. A formal deprecation policy might be a good start. The C language really should be considered the gold standard here. Changes did have to be made, like getting rid of the notoriously broken and insecure gets(), but they were made very, very slowly and unobtrusively. (I do think lpad should except "any" FWIW) :-D merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers