Re: UTF-8 context of BYTEA datatype??

On Thu, 2006-06-01 at 02:00 +0000, Greg Sabino Mullane wrote:
> #!perl
> 
> package testone;
> use DBI;
> 
> printf "SQL_INTEGER is %d\n", SQL_INTEGER;
> 
> package testtwo;
> use DBI qw(:sql_types);
> 
> printf "SQL_INTEGER is %d\n", SQL_INTEGER;

But this is not as bad as having to "use DBD:Pg" (or any other dviver
speciffic include).

> unlike most other data types, it is very important that DBD::Pg (and libpq,
> and the backend) be told explicitly that a binary string is being used,
> so that the length can be sent, as a null character may not represent the
> end of the string.

Well, for a humble utility programmer like myself - not really knowing
the internals - it's *very* desirable to be able to just "CREATE TABLE"
with 'binary' column, and as a result, have the client library know
that, and act on provided data accordingly.

The most desirable state is when my script works equally well with any
driver - like in case, when the sriver is selected on command line (and
I don't really mean here "eval 'require $ARGV[0]'" :).

> Martijn van Oosterhout asked:
> >
> > Why isn't PQexecPrepared always used? And why does typing it
> > SQL_BINARY not do the same?
> 
> SQL_BINARY is not the same as PG_BYTEA - we don't necessarily handle binary
> strings the same way as other databases. Still, it may be worth revisiting

This is something I don't understand.

As a programmer, I have *chosen* the PG_BYTEA (or to be precise: I've
chosen to: "CREATE TABLE test (img BYTEA)"), just to have the
functionality of a binary opoque value - not interpretted in any way by
the RDBMS (like: not converted according to clinet_encoding).

In my opinion I meant SQL_BINARY.

So if in the postresql RDMBS, there is no other datatype closer to the
SQL_BINARY semantics, the PG_BYTEA should be just a synonym.

-- 
Rafal Pietrak