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 <rafal@poczta.homelinux.com>