tip78,

лучше такие вопросы задавать в местах посвящённых именно языку программирования. Потому что к базе нюансы реализации клиентской библиотеки доступа в общем-то не относятся.
Ну да впрочем могу ответить как старый php разработчик.

Механизм исключений появился в PHP уже давно, но он существует отдельно от механизма ошибок (ещё более старого). Эта картина начала меняться с выходом php7.0 но не в кардинальном виде изменить сразу всё и кидать исключения абсолютно везде где раньше были ошибки, а постепенно даже в ядре, не то что в штатных модулях.
Поэтому catch в принципе не будет ловить ошибки, он ловит только исключения.
pg_query исключения кидать не умеет в том числе в наиболее актуальном релизе 7.2.1: https://github.com/php/php-src/blob/PHP-7.2.1/ext/pgsql/pgsql.c#L1873 Макрос PHP_PQ_ERROR объявлен выше и является простой обёрткой над генерацией E_WARNING.

Распространённой практикой разработки в PHP является зарегистрировать глобальный обработчик всех ошибок через set_error_handler , в котором бросать исключение. Это и в разработке удобнее, исключение не заметить куда сложнее чем E_NOTICE где-нибудь и позволяет штатные ошибки преобразовывать в исключения и ловить простым try catch.

И второй момент - за много лет работы я честно ни разу не видел использования именно pgsql модуля к базе. Обычно используется PDO, который и исключения кидать умеет нативно (опция PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION) и умеет эмуляцию prepared statements (PDO::ATTR_EMULATE_PREPARES => true) что позволяет использовать внятный API prepared statements и не иметь проблем с пулом транзакций pgbouncer'а.

tip78НЕбезопасен
Вы, конечно, сможете дать линки на заведённые баги? А то полмира пользуется, надо бы предупредить всех фреймворкописателей. Хотя странно, рабочего эксплоита что-то не видно уже второе десятилетие, к чему бы это?.. Только не ссылайтесь пожалуйста на кавычки gbk локали при неверно поставленной charset в dsn, это не серьёзно (если к postgresql вообще применимо, что отдельно специально проверять надо этот крайне узкий случай).
libpq PQexecParams никакой магии не делает. pdo_pgsql уходит в тот же самый PQsendQueryGuts в libpq в конечном итоге.

tip78а всякие mysql, mysqli и PDO за столько лет так до ума и не довели
mysql и не собирались доводить, уже лет 15+ как был deprecated (фактических, а не когда начал кидать E_DEPRECATED), а нынче наконец-то вовсе удалён
mysqli - да, на мой взгляд неудобный api, особенно в prepared statements секции.
pgsql совершенством вы назвать тоже не сможете, иначе вы бы не задавали обсуждаемый вопрос
Совершенства здесь нигде нет, пишите в internals предложения по улучшениям.

Да и в целом - хотите использовать ext/pgsql - пожалуйста. Выбор есть и это хорошо. Как нормально ловить ошибки я написал.

tip78 https://habrahabr.ru/post/148701/
И где же вы там нашли небезопасность PDO? Автор даже сам настаивает на эмуляции prepared statements и прикручивает очередной велосипед неясной геометрии колёс к mysqli.

Насчёт полмира - зависит от определения мира. Для шарика Земли может и многовато, для мира PHP разработки - может и маловато.