Re: Speeding up loops in pl/pgsql function

From: Steve Crawford <scrawford(at)pinpointresearch(dot)com>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: "Reuven M(dot) Lerner" <reuven(at)lerner(dot)co(dot)il>, Alex Hunsaker <badalex(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Speeding up loops in pl/pgsql function
Date: 2011-05-26 15:24:45
Message-ID: 4DDE70BD.2060205@pinpointresearch.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On 05/26/2011 05:36 AM, Merlin Moncure wrote:
> ...
> got it:
> select decode(regexp_replace('141142143', '([0-9][0-9][0-9])',
> $q$\\\1$q$ , 'g'), 'escape');
> decode
> --------
> abc
> (1 row)
>
> merlin
>
Nice. A word of warning, in 9.0 this returns a hex string:

select decode(regexp_replace('141142143', '([0-9][0-9][0-9])',
$q$\\\1$q$ , 'g'), 'escape');
decode
----------
\x616263

See http://www.postgresql.org/docs/9.0/static/release-9-0.html:

E.5.2.3. Data Types
bytea output now appears in hex format by default (Peter Eisentraut)
The server parameter bytea_output can be used to select the
traditional output format if needed for compatibility.

Another wrinkle, the function I wrote sort of ignored the bytea issue by
using text. But text is subject to character-encoding (for both good and
bad) while bytea is not so the ultimate solution will depend on whether
the input string is the octal representation of an un-encoded sequence
of bytes or represents a string of ASCII/UTF-8/whatever... encoded text.

Cheers,
Steve

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Merlin Moncure 2011-05-26 15:36:18 Re: The shared buffers challenge
Previous Message Kevin Grittner 2011-05-26 15:10:13 Re: The shared buffers challenge