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@xxxxxxxxxxxxxxxxxxxx>
