El día jueves, octubre 10, 2019 a las 06:46:02p. m. +0200, Francisco Olarte escribió:
> Matthias:
>
> On Thu, Oct 10, 2019 at 1:25 PM Matthias Apitz <guru@unixarea.de> wrote:
> > I can SELECT && print a column in hex with:
> > pos71=# select d02name::bytea from d02ben where d02bnr = '00001048313' ;
> > ...
> > \x50c3a46461676f67697363686520486f6368736368756c65205765696e67617274656e2020 ...
> >
> > but when I use the same in Perl DBI::Pg with:
> > $sth=$dbh->prepare( "select d02name::bytea from d02ben where d02bnr = '00001048313'");
> ...
> > It prints the UTF-8 string and not the hex string:
>
> May be because perl does not need the contents in hex DBI converts it
> to a native string, which is very similar to a "bytea" inside the db (
> not in the wire protocol, but it does a similar thing for numbers ).
Hmm. But *I* do need the content in hex to see if the varchar column
contains correct encoded UTF-8 data. We're on the way to port a huge
database application from Sybase to PostgreSQL and are facing any kind of
problems one can think of. Magically, sometimes strings, expected to be
coded in UTF-8, arrive in the Perl $variables coded in ISO-8859-1 and than cause
other problems when German Umlauts should be translated into HTML
encodings like ü etc. to be presented in the web browser.
Perl (and Java) sucks, it does magic things below the surface of
string (objects). That's why I like C :-)
matthias
--
Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub