Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UQ6DV-0003An-G9 for pgsql-admin@arkaria.postgresql.org; Thu, 11 Apr 2013 01:22:21 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1UQ6DU-0003wI-Tf for pgsql-admin@arkaria.postgresql.org; Thu, 11 Apr 2013 01:22:20 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UQ6DT-0003vb-QF for pgsql-admin@postgresql.org; Thu, 11 Apr 2013 01:22:20 +0000 Received: from mail-ie0-x22f.google.com ([2607:f8b0:4001:c03::22f]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UQ6DQ-00057u-EH for pgsql-admin@postgresql.org; Thu, 11 Apr 2013 01:22:18 +0000 Received: by mail-ie0-f175.google.com with SMTP id c12so1373249ieb.20 for ; Wed, 10 Apr 2013 18:22:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=COvAjTYwJJ26l6HFDmvnnKnVNQNZI4n3R0HeFPiKcSg=; b=CWPy1CCqz8+eiLKslFXi12ms17uOQF8p4/wjSBPrDKUlZ1iCjEEdRpB9FL8jV42wfS t/BXIT1zh8lnt3pw/TvibbfStxqSWwTCehkslUACnTuilqM5v17xf2T3xrLs4bOsW5EO gKZt4gmEuI2ikpyom1AVHr6D4j5wpsDkqBf18OTjs3Z9KgWRJuQSfZDDYMhjDwLDb8th VWpIlLnLsooI3TY4mp3lHdSGYbfMxh1GnQBwCvSyuVnvwuC/EWK/PCFmgyBQcOnqnV7V H5c2LhlDELa1oglIjYABa6s6TGiA8AfU3tYULsn+wCS5O9YgiTWoO1AfIRl0Eg87fAfY TfqA== X-Received: by 10.50.194.229 with SMTP id hz5mr3025592igc.111.1365643335474; Wed, 10 Apr 2013 18:22:15 -0700 (PDT) Received: from [10.88.222.235] ([166.137.97.96]) by mx.google.com with ESMTPS id xe9sm475084igb.7.2013.04.10.18.22.13 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Apr 2013 18:22:14 -0700 (PDT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-31D9506D-827D-406A-9474-4119E3B2E89C Content-Transfer-Encoding: 7bit Message-Id: <82B7E288-2DE2-47AF-8DDB-CB488BDD6262@gmail.com> Cc: "pgsql-admin@postgresql.org" X-Mailer: iPhone Mail (10B329) From: Armin Resch Subject: Re: regexp_replace grief Date: Wed, 10 Apr 2013 20:22:13 -0500 To: Craig James X-Pg-Spam-Score: -2.0 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-admin Precedence: bulk Sender: pgsql-admin-owner@postgresql.org --Apple-Mail-31D9506D-827D-406A-9474-4119E3B2E89C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Thx for clarification, Craig. Your Perl snippet comes in handy, too. -ar On Apr 10, 2013, at 8:08 PM, Craig James wrote: > On Wed, Apr 10, 2013 at 4:59 PM, Armin Resch wrote: >> Not sure this is the right list to vent about this but here you go: >>=20 >> I) select regexp_replace('BEFORE.AFTER','(.*)\..*','\1','g') "Substring" >> II) select regexp_replace('BEFORE.AFTER','(.*)\\..*','\\1','g') "Substrin= g" >>=20 >> Executing (II) against pg 8.4.4 or 9.0.4 yields 'BEFORE', but in order fo= r 9.1.7 to yield the same one has to execute (I) .. bummer >=20 > This has nothing to do with regexp's. It's a change in how '\' is interpr= eted in any quoted string. The change came with Postgres 9.x and is documen= ted in the release notes. It brings Postgres into compliance with the SQL s= tandard. >=20 > In Perl, I do something like this: >=20 > my $pg_bs_char; > if ($dbh->get_info($GetInfoType{SQL_DBMS_VER}) gt "09.00.00") { > $pg_bs_char =3D "\\"; # a single '\' for PG 9.1 and higher > } else { > $pg_bs_char =3D "\\\\"; # a double '\\' for PG up to 9.0 > } >=20 > You can also revert to the old 8.x interpretation; see >=20 > http://www.postgresql.org/docs/9.1/static/runtime-config-compatible.html= >=20 > Craig > =20 >>=20 >> -ar >=20 --Apple-Mail-31D9506D-827D-406A-9474-4119E3B2E89C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Thx for clarification, Craig. Your Perl snippet comes in handy, too.
-ar

On Apr 10, 2013, at 8:08 PM, Craig James <cjames@emolecules.com> wrote:

On Wed, Apr 10, 2013 at 4:59 PM, Armin Resch <reschab@gmail.com> wrote:
Not sure this is the right list to vent about this but here you go:

I) select regexp_replace('BEFORE.AFTER','(.*)\..*','\1','g') "Substring"
II) select regexp_replace('BEFORE.AFTER','(.*)\\..*','\\1','g') "Substring"

Executing (II) against pg 8.4.4 or 9.0.4 yields 'BEFORE', but in order for 9.1.7 to yield the same one has to execute (I) .. bummer

This has nothing to do with regexp's.  It's a change in how '\' is interpreted in any quoted string.  The change came with Postgres 9.x and is documented in the release notes.  It brings Postgres into compliance with the SQL standard.

In Perl, I do something like this:

my $pg_bs_char;
if ($dbh->get_info($GetInfoType{SQL_DBMS_VER}) gt "09.00.00") {
    $pg_bs_char = "\\";         # a single '\' for PG 9.1 and higher
} else {
    $pg_bs_char = "\\\\";       # a double '\\' for PG up to 9.0
}

You can also revert to the old 8.x interpretation; see

  http://www.postgresql.org/docs/9.1/static/runtime-config-compatible.html

Craig
 

-ar

--Apple-Mail-31D9506D-827D-406A-9474-4119E3B2E89C--