On Mon, Jan 9, 2017 at 6:53 PM, Jim Nasby <jim.na...@bluetreble.com> wrote: > I do think that whichever route we go, we're going to be stuck supporting > the old version for a LONG time. A big part of why > standard_conforming_strings was so ugly is users didn't have enough time to > adjust. If we'd had that enabled by default for 4-5 releases it wouldn't > have been nearly as much of an issue.
/me boggles. I think you are confused about the history here. standard_conforming_strings had a generously long phase-in period. - 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). -- 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
