Re: Inefficient escape codes.

From: Peter Childs <peterachilds(at)gmail(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: Inefficient escape codes.
Date: 2005-10-19 07:19:04
Message-ID: a2de01dd0510190019v54de5097i@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On 18/10/05, Michael Fuhr <mike(at)fuhr(dot)org> wrote:
> [Please copy the mailing list on replies so others can participate
> in and learn from the discussion.]
>
> On Tue, Oct 18, 2005 at 07:09:08PM +0000, Rodrigo Madera wrote:
> > > What language and API are you using?
> >
> > I'm using libpqxx. A nice STL-style library for C++ (I am 101% C++).
>
> I've only dabbled with libpqxx; I don't know if or how you can make
> it send data in binary instead of text. See the documentation or
> ask in a mailing list like libpqxx-general or pgsql-interfaces.
>
> > > Binary transfer sends data in binary, not by automatically converting
> > > to and from text.
> >
> > Uh, I'm sorry I didn't get that... If I send: insert into foo
> > values('\\001\\002') will libpq send 0x01, 0x02 or "\\\\001\\\\002"??
>
> If you do it that way libpq will send the string as text with escape
> sequences; you can use a sniffer like tcpdump or ethereal to see this
> for yourself. To send the data in binary you'd call PQexecParams()
> with a query like "INSERT INTO foo VALUES ($1)". The $1 is a
> placeholder; the other arguments to PQexecParams() provide the data
> itself, the data type and length, and specify whether the data is in
> text format or binary. See the libpq documentation for details.
>

You could base64 encode your data admitiaddly increasing it by 1/3 but
it does at least convert it to text which means that its more
unserstandable. base64 is also pritty standard being whats used in
EMails for mime attachments.

Peter

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Katherine Stoovs 2005-10-19 14:51:55 tuning seqscan costs
Previous Message Michael Fuhr 2005-10-18 20:47:27 Re: Inefficient escape codes.