полностью согласен с st_serg ,
...
-админить такую бд с ерормесагами типа "Обновление невозможно" наверно афигительно удобно?
-а пофигу что у нас бесполезный тригер... потом будем на форумах спрашивать "а че у меня апдейты тормозят.?"
- а если у нас по другим причинам апдейт не прошел? а вот грохнутся у нас конект когда мы апдейт делали? или еще че нить с БД? других ошибок база что-ли делать не умеет и Libpq у нас тоже ошибки рожать не умеет совсем ..да?
...

имхо решение для ленивых, понятно что написать PqExecute() if(error) { printf("%s",error) }
проще всего и вроде как все красиво..

з.ы. у меня в конторе за такое бы ноги оторвали.. а потом только спрашивали.. причем не аргументы,а где я травы такой взял.

>3. кто вам сказал, что изменяется текст сообщений о других ошибках?

ты немного непонял.

могу предположить что ошибка нарушения повторного ключа вполне естественна для клиенской части и в принципе отрабатывается(все ошибки этого запроса не вызывают критикал исключения), при этом человек хочет как-то ее обозначить текстом.. желание сделать так, чтоб этот текс выдавала база может быть только в случае если в клиенте написанно
PqExecute() if(error) { printf("%s",error) }
в этом случае клиент при других ошибках получит так им не желаемый посгревый текс ошибки..
т.е. как мертвому припарка.

далее..
может быть ситуация что у чела там в коде нечто типа
PqExecute(); if(error = "Обновление невозможно") { printf("%s",error) } else { throw exception };
что тоже криво..
можно вставить код ошибки как ты сказал.. но хмм.. разносить константы(номера ошибок) по базе и коду... не фантан решение.

если там Id ПК то клиенский код который может такое понадобится выглядит как то так:
то запрос видимо такой "updata table set id=$new_id where id=$old_id...."
по моему имхо, это не безапастно..и таких вещей лучше избегать, я с необходимостью такого запроса не сталкивался никогда..

я бы наверно первое что попытался сделать это определить через ошибку бибилиотеки тип ошибки,
если не получится, попробывал бы через функцию типа update_some_table(); возвращаюшую соответственно 0/1.

исключительно из таких соображений я писал свой пост..
ибо других ситуация когда предложенное в начале решение будет удобное, безопасное, "прямое" и т.д. я представить не могу никак..
имхо спор помойму движется в сторону "хранимые процедуры" vs "код на клиенте"

странность номер 2 :
такой тригер(в первом посте) запрешает обновлять уже существующие записи.
т.е. инсертить я могу и могу менять ПК у записи и удалять записи...
ну это я конечно придираюсь уже :) конечно там в ифе условие пропущено.

а мож там у человека ограниченный набор ID и в клиенте написан код для переиспользования идишников... вобщем все странно и как-то неправильно изначально :)