Re: merging some features from plpgsql2 project

2017-01-05 18:36 GMT+01:00 Merlin Moncure <mmoncure(at)gmail(dot)com>:

> On Thu, Jan 5, 2017 at 11:03 AM, Robert Haas <robertmhaas(at)gmail(dot)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
>

I fully agree - sometimes there is fuzzy border in understanding what is
bug and what unhappy designed feature - probably lot of useful features can
be taken and used wrong.

Regards

Pavel

>
> merlin
>