Skip site navigation (1) Skip section navigation (2)

Re: [PATCHES] PQescapeBytea documentation patch

From: Joe Conway <joseph(dot)conway(at)home(dot)com>
To: Patrick Welche <prlw1(at)newn(dot)cam(dot)ac(dot)uk>
Cc: pgsql-interfaces(at)postgresql(dot)org
Subject: Re: [PATCHES] PQescapeBytea documentation patch
Date: 2001-11-21 17:04:41
Message-ID: 3BFBDEA9.3070703@home.com (view raw or flat)
Thread:
Lists: pgsql-docspgsql-interfacespgsql-patches
Patrick Welche wrote:

> This makes me wonder: should libpq contain a function to do the opposite
> too? eg.
> 
> string=GetValue(from a bytea type column)
> PQunescapeBytea(string, some buffer, buffer's size)
> 
> - or is there already another way of doing it?
> 
> It seems to me that anyone using bytea with libpq will end up having
> to reinvent this wheel. (Something worthy of being knocked up in my
> Copious Free Time (tm))

I thought about that, but did not write it for a couple of reasons:

First, there wasn't a strong consensus that this type of function 
belonged as part of libpq in the first place, so I didn't want to push 
my luck ;-)

Second, at least in my current work, I'm using binary cursors, in which 
case no unescaping is necessary.

I do agree that a standard bytea unescape function should be available 
in the client library somewhere. Maybe for 7.3 . . .

Joe


In response to

pgsql-docs by date

Next:From: Joe ConwayDate: 2001-11-21 17:12:13
Subject: Re: Oracle -> PostgreSQL ==> RAW -> ???
Previous:From: Ezra EpsteinDate: 2001-11-21 15:32:04
Subject: Oracle -> PostgreSQL ==> RAW -> ???

pgsql-patches by date

Next:From: Tom LaneDate: 2001-11-21 17:54:31
Subject: Re: Rejection of the smallest int8
Previous:From: Bruce MomjianDate: 2001-11-21 16:49:04
Subject: Re: [PATCHES] Version checking when loading psql

pgsql-interfaces by date

Next:From: Darko PrenosilDate: 2001-11-21 18:41:20
Subject: TTY debug
Previous:From: Chitta BarikDate: 2001-11-21 15:50:37
Subject: closing connection while cancelling

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group