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@xxxxxxxxxxx> 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@xxxxxxxxxxx, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub
