X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org
Received: from localhost (av.hub.org [200.46.204.144])
	by svr1.postgresql.org (Postfix) with ESMTP id 53533D82B7
	for <pgsql-performance-postgresql.org@localhost.postgresql.org>;
	Fri, 21 Oct 2005 13:59:46 -0300 (ADT)
Received: from svr1.postgresql.org ([200.46.204.71])
	by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
	with ESMTP id 70072-08
	for <pgsql-performance-postgresql.org@localhost.postgresql.org>;
	Fri, 21 Oct 2005 16:59:40 +0000 (GMT)
Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.203])
	by svr1.postgresql.org (Postfix) with ESMTP id 300FDD6E85
	for <pgsql-performance@postgresql.org>;
	Fri, 21 Oct 2005 13:59:38 -0300 (ADT)
Received: by wproxy.gmail.com with SMTP id i5so408770wra
	for <pgsql-performance@postgresql.org>;
	Fri, 21 Oct 2005 09:59:30 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references;
	b=HLklKjpSGTNzeiKfTun9qouBPvTG6sIoKzhrWipNgAW0ROfuwaJgboq3Tnxn8GwLPIzZxFpGhB8/E2BHWTwabiwAXQuzCMEb9N3+DMgIJupcNIqgYYq010GXWiicvnwGADq28UIDlwTkwR53Idoyr0Al1BCbZrXAOdNiMsG9QjI=
Received: by 10.54.34.19 with SMTP id h19mr1171222wrh;
	Fri, 21 Oct 2005 09:59:30 -0700 (PDT)
Received: by 10.54.103.6 with HTTP; Fri, 21 Oct 2005 09:59:30 -0700 (PDT)
Message-ID: <3cf983d0510210959y32fdb891gff11bfbaf1943ebe@mail.gmail.com>
Date: Fri, 21 Oct 2005 16:59:30 +0000
From: Rodrigo Madera <rodrigo.madera@gmail.com>
To: =?ISO-8859-1?Q?N=F6rder-Tuitje=2C_Marcus?= <noerder-tuitje@technology.de>
Subject: Re: Inefficient escape codes.
Cc: pgsql-performance@postgresql.org
In-Reply-To: 
 <16F953410A0F1346848DCB476A989CFE01D557@swtexchange2.technology.de>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_23801_12446235.1129913970877"
References: 
 <16F953410A0F1346848DCB476A989CFE01D557@swtexchange2.technology.de>
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, hits=0.233 required=5 tests=[AWL=-0.087, HTML_10_20=0.295,
	HTML_MESSAGE=0.001, RCVD_BY_IP=0.024]
X-Spam-Level: 
X-Archive-Number: 200510/301
X-Sequence-Number: 15069

------=_Part_23801_12446235.1129913970877
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

> I guess, You should check, if a blob field and large object access is
> suitable for you - no escaping etc, just raw binary large objects.
>
> AFAIK, PQExecParams is not the right solution for You. Refer the "Large
> object" section:
>
> "28.3.5. Writing Data to a Large Object
> The function
> int lo_write(PGconn *conn, int fd, const char *buf, size_t len);writes le=
n
> bytes from buf to large object descriptor fd. The fd argument must have b=
een
> returned by a previous lo_open. The number of bytes actually written is
> returned. In the event of an error, the return value is negative."


Well, I read that large objects are kept in only ONE table. No matter what,
only the LOID would be kept. I can't affor that since I hav lots of tables
(using the image-album-app analogy, imagine that we have pictures from
several cities, each one corresponding to a city, like Memphis_Photos,
Chicago_Photos, etc.).

This is one major drawback, isn't it?

Rodrigo

------=_Part_23801_12446235.1129913970877
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<br>
<div><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(=
204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I
guess, You should check, if a blob field and large object access is
suitable for you - no escaping etc, just raw binary large objects.<br><br>A=
FAIK, PQExecParams is not the right solution for You. Refer the &quot;Large=
 object&quot; section:<br><br>&quot;28.3.5. Writing Data to a Large Object
<br>The function<br>int
lo_write(PGconn *conn, int fd, const char *buf, size_t len);writes len
bytes from buf to large object descriptor fd. The fd argument must have
been returned by a previous lo_open. The number of bytes actually
written is returned. In the event of an error, the return value is
negative.&quot;</blockquote><div><br>
Well, I read that large objects are kept in only ONE table. No matter
what, only the LOID would be kept. I can't affor that since I hav lots
of tables (using the image-album-app analogy, imagine that we have
pictures from several cities, each one corresponding to a city, like
Memphis_Photos, Chicago_Photos, etc.).<br>
<br>
This is one major drawback, isn't it?<br>
<br>
Rodrigo<br>
</div><br>
</div><br>

------=_Part_23801_12446235.1129913970877--