-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rafal Pietrak asked: > 2. I admitt, that I should have spotted myself, that the > DBD::Pg::PG_BYTEA might not have been recognized without the use > clausure, but the driver itself understands prity much of the > underlaying datatypes - I fon't need to bind explicitly for SQL_DATE or > SQL_INTEGER. Why should I care more for binary objects? SQL_INTEGER and SQL_DATE are generic data types, and come from DBI. DBD::Pg::PG_BYTEA, as you might guess from the name, comes from DBD::Pg. However, *all* of them have to be loaded explicitly - this is by design. For example, try running this script: #!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; If you are asking why the bind has to happen at all, it is partly because libpq does not support returning the data types yet, and partly because 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. Martijn van Oosterhout asked: > Actually, this is the case already. When a parameter is explicitly > typed as bytea, then libpq's PQexecPrepared is used and the binary > contents are passed outside of the query. > > 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 if we can do something a little more intuitive, so I'll revisit this. As far as PQexecPrepared, there are many reasons for not using it - insufficient PG version, using DDL, having a DEFAULT in your query, etc. But in general, DBD::Pg does its best to use it (and PQexecParams) whenever possible. - -- Greg Sabino Mullane greg@xxxxxxxxxxxx PGP Key: 0x14964AC8 200605312152 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iD8DBQFEfknRvJuQZxSWSsgRAt33AJ9NS2LFwSyoYSHgEjLbYUSCvr/kTQCfXUPR v/RpO73hIhY7CwXVcaqwCKI= =zXCq -----END PGP SIGNATURE-----
