Re: merging some features from plpgsql2 project

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Joel Jacobson <joel(at)trustly(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Marko Tiikkaja <marko(at)joh(dot)to>
Subject: Re: merging some features from plpgsql2 project
Date: 2017-01-12 03:21:50
Message-ID: CAHyXU0xe8A9L=yYYSENu85WUMHa9JEiQaNKqTic+bRdMJv5_yQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jan 11, 2017 at 2:57 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> - The E'' syntax and the standard_conforming_strings GUC were added in
> PostgreSQL 8.0. The only legal value of standard_conforming_strings
> was "false".
>
> - In PostgreSQL 8.1, it became possible to set
> standard_conforming_strings to "true", but the default was still
> "false".
>
> - In PostgreSQL 9.1, the default was changed to "true".
>
> So there 6 major release from the time the GUC was added and 5 from
> the time it became mutable before the default was flipped. We've now
> had 5 more since the default was changed to "true". (No, it's not
> time to remove the GUC yet. At least not in my opinion.)
>
> One thing that made changing standard_conforming_strings particularly
> painful was that it had knock-on effects on many language-specific
> drivers not maintained by the core project (or just plain not
> maintained). I don't think the language changes being proposed here
> for PL/pgsql would have the same kind of impact, but some of them
> would make it significantly harder to migrate to PostgreSQL from
> Oracle, which some people might see as an anti-goal (as per other
> nearby threads on making that easier).

I don't think it's a simple matter of waiting N or N+M releases
(although I certainly did appreciate that we did it regardless). It
comes down to this: there's just no way to release changes that break
a lot of code without breaking a lot of code. It's all about
acknowledging that and judging it acceptable against the benefits you
get. For posterity, with respect to conforming strings, SQL
injection is an absolute scourge of the computing world so on balance
we did the right thing. Having said that, It's always good to do the
math and the calculation is primarily an economic one, I think,

merlin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2017-01-12 03:25:33 Re: Passing query string to workers
Previous Message Robert Haas 2017-01-12 03:21:46 Re: parallelize queries containing subplans