perl dbi

Проверь кодировку в своем терминале и советую посмотреть в сторону https://metacpan.org/pod/DBIx::Connector

# locale
LANG=ru_RU.UTF-8
LANGUAGE=
LC_CTYPE="ru_RU.UTF-8"
LC_NUMERIC="ru_RU.UTF-8"
LC_TIME="ru_RU.UTF-8"
LC_COLLATE="ru_RU.UTF-8"
LC_MONETARY="ru_RU.UTF-8"
LC_MESSAGES="ru_RU.UTF-8"
LC_PAPER="ru_RU.UTF-8"
LC_NAME="ru_RU.UTF-8"
LC_ADDRESS="ru_RU.UTF-8"
LC_TELEPHONE="ru_RU.UTF-8"
LC_MEASUREMENT="ru_RU.UTF-8"
LC_IDENTIFICATION="ru_RU.UTF-8"
LC_ALL=

а чем DBIx::Connector лучше DBI?

Присоединяюсь к вопросу ТС (чем лучше).

А также добавочный: Что из этого умеет в препаред стейтмент с/без эмуляции? Умеет ли в именованые плейсхолдеры? Биндинг по типам (строка, целое и т.д.)? Возврат в правильном типе (строка, целое и т.д.)?

ТС — кроме кодировки терминала, проверь и кодировку всех своих файлов, в которых ты пишешь свой код.

большой плюс, что он за тебя следит за форками, имеет внятный run/txn интерфейс, может автоматически перезапустить запрос если вдруг протух коннект (привет, мыскуль), а при небольшой доработке (унаследованный класс) можно вообще рестарт запроса делать в ожидании пока дб вернётся

Если версия DBD::Pg >= 3, то лучше будет без флагов pg_enable_utf8, pg_utf8_flag

https://metacpan.org/pod/DBD::Pg#pg_enable_utf8-(integer)

убирал эти флаги. ничего не меняется. как я понимаю, эти флаги говорят что БД будет работать с кодировкой UTF8, но до бд дело еще не дошло, соединение, не установлено!!!

Попробуй use open qw(:std :utf8); А вообще ты все правильно делаешь, декодить ручками самое надежное в этом недоязычке.

видимо не исправили: https://rt.cpan.org/Public/Bug/Display.html?id=53854#txn-723546

т.е. завести новый bug-report или декодировать

автоматически перезапустить запрос если вдруг протух коннект

persistent connection штоле?

А добавочный вопрос ты зачем проигнорировал?

если в селекте написать не существующую таблицу, то ошибка выводится читаемой, что случилось с коннектом?!!

когда соединение установлено, то декодируется в соответствии с client encoding ( опять же судя по https://rt.cpan.org/Public/Bug/Display.html?id=53854#txn-723546 )

=> декодировать errstr, только если падает DBI->connect

баг репорт заводить?

Сто лет назад пофиксили же.

The bug has been fixed in subversion r13749. If you would like 
to confirm the fix locally, it's a small patch to the
dbdimp.c file:

Index: dbdimp.c
===================================================================
--- dbdimp.c    (Revision 13667)
+++ dbdimp.c    (Arbeitskopie)
@@ -271,6 +271,10 @@
        sv_setpvn(DBIc_ERRSTR(imp_xxh), error_msg, error_len);
        sv_setpv(DBIc_STATE(imp_xxh), (char*)imp_dbh->sqlstate);

+       /* Set as utf-8 */
+       if (imp_dbh->pg_enable_utf8)
+               SvUTF8_on(DBIc_ERRSTR(imp_xxh));
+
        if (TEND) TRC(DBILOGFP, «%sEnd pg_error\n», THEADER);

 } /* end of pg_error *

если 100 лет назад профиксили, то почему у меня не работает как должно? версии пакетов обновил, свежее некуда

Может опять сломали. Бывает.

да

$dbh = DBI->connect($data_source, $username, $password, {‘pg_enable_utf8’ => 1,‘pg_utf8_flag’ => 1}) or die $DBI::errstr;

Прямо чувствуется рука мастера:

<?php

$res = mysql_query("some sql") or die("Hacking attempt!");

Как часто я подобное видел в PHP и как-то не задумывался, что это просто перловики сменили работу.