Re: bytea escaping

From: Hannu Krosing <hannu(at)tm(dot)ee>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Joe Conway <joseph(dot)conway(at)home(dot)com>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: bytea escaping
Date: 2001-08-29 10:04:30
Message-ID: 3B8CBE2E.7355F3A6@tm.ee
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
>
> "Joe Conway" <joseph(dot)conway(at)home(dot)com> writes:
> > ... is there a good reason that byteaout
> > octal escapes all non-printable characters?
>
> Well, AFAICS it *has to* escape nulls (zero bytes). Whether it escapes
> more stuff is a matter of taste once you accept that.

output function seems to escape all bytes <=\027 and >=\177

> What we really need to have to make bytea more useful is direct read and
> write functions that don't require any escaping (a la large object
> lo_read/lo_write).

Two intertwined things we are currently missing:

1) a portable BINARY protocol (i _think_ that's what the typreceive and
typsend
fields in pg_type are meant to implement - currently they are allways
the same as
typinput, typoutput)

hannu=# select count(*) from pg_type where typreceive != typinput or
typsend != typoutput;
count
-------
0
(1 row)

2) a FE-BE protocol that allows first PREPARING a statement and then
EXECUTEing
it with args. Most DB's have it, SPI has it and both ODBC and JDBC have
it.
This should use the above-mentioned protocol to send the arguments to
execute.

having LO access to things is also nice, but it is independent of being
able to
easily store binary data in a database, especially if we claim PG to be
an ORDBMS.

-------------
Hannu

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message omid omoomi 2001-08-29 10:11:16 Re: [SQL] getting the oid for a new tuple in a BEFORE trigger
Previous Message Thomas Swan 2001-08-29 09:56:20 Re: bugs - lets call an exterminator!