On Mon, 2006-05-29 at 14:01 +0200, Martijn van Oosterhout wrote:
> >
> > How come the bytearea is *interpreted* as having encoding?
>
> Actually, it's not the bytea type that is being interpreted, it's the
> string you're sending to the server that is. Before you send bytea data
> in a query string, you have to bytea encode it first. The DBD::Pg
> manpage seems to suggest something like:
>
> $rv = $sth->bind_param($param_num, $bind_value,
> { pg_type => DBD::Pg::PG_BYTEA });
>
Hmmm, despite initial euphoria, this doesn't actually work.
Subsequently I've also tried putting SQL_BINARY in place of that
hash-ref, and plain DBD::Pg::PG_BYTEA, and also I tried to use 'TYPE =>'
instead of pg_type. (All those hints in man DBI). None of that worked
either.
But I also did:
$db->do('SET client_encoding = LATIN1') or die "SET";
just after connect and before prepare, and this produced a slightly
different result.... no ERROR, but the image was cut short to 9-bytes
inside the database data-row.
Would perl have interpreted this command according to it's semantics?
And change it's own default string handling accordingly!?
Not knowing the internals, I wouldn't bet on whichever, but I have my
doughts - my quess is thet DBI driver doesn't go that far. So if it
hasn't interpretted the 'SET client_encodding' internally, but just
passed that to database, the only thing that changed is the database
frontend context.
So may be the original error came from the database itself anyway?
Any ideas? (still hopping I wont have to write a C-level interface
function just to test what's really happening.... :)
--
-R
