конечно они

Эммм? Перезаписывать по столбцам? Никогда? Потому что MVCC и  по сути update == delete + insert?

> по сути update == delete + insert?

Это только в первом приближении, и не обязано быть так, в принципе.
Либо что-то ещё мешает этому, либо это на самом деле почти никому не нужно (а уж блокирование на уровне полей — это вообще что-то очень странное — "всего лишь" нужно пересмотреть / обдумать весь связанный с этим функционал (и код) — а ради чего, мне как-то непонятно, например... да и в других СУБД такого совсем нет, насколько я помню).

я имею в виду чтобы блокировка на апдейт какого-то поля не мешала менять другие поля

Это сложно сделать и сложно доказать ,что это будет стабильно работать , а не ломаться постоянно

всем привет, подскажите плз, как убрать видимость других баз данных для пользователя

смотрю через пгадмин, но видны почему-то все базы данных на сервере
а это не надо

Ну да крайне упрощённо, но не расписывать же как MVCC устроен полностью. Собственно я и веду к тому, что, в силу подобного устройства MVCC на  базовом уровне, поколоночные блокировки (и тем более апдейты) невозможны без переписывания огромного объёма кода. Никто на это не пойдёт - профит не стоит ни затраченных усилий, ни репутационных потерь проекта по причине того, что у кого-то всё обязательно сломается нафиг.

Суть в том, что поле отдельно прямо в строке не меняется. ОЧЕНЬ грубо говоря, мы пишем полностью новую копию всей строки, а старую стираем. Блокировать всю строку в такой ситуации - вынужденная мера.

я знаю как это работает, но это очень мешает жить

особенно при каскадных операциях

Ну блин, мне мешает жить наличие всего двух рук и необходимость спать  треть суток) А фигли делать то? Так устроено, переделать сложно.

приходится делать костыли, разбивать таблицы на несколько

это просто крик души. забей

Насколько я помню, никак.

Я к тому, что UPDATEs проще блокировок в этом отношении, с виду.
А какой вообще мог бы быть profit от таких блокировок, и зачем вообще "разбивать таблицы на несколько", я как-то так и не понял. ;(

это вроде можно, но вроде и не получается

Хмм... покажете, как "вроде можно"?

REVOKE SELECT ON pg_catalog.pg_roles FROM public;
или
еще видел с таким: SET search_path=schema_name

Ну какие-нибудь высококонкуррентные операции над длинным рядом метрик в отдельных столбцах могу сходу придумать например. Один счетчик инкрементировать, другой одновременно переписать на новое значение, ещё пяток значений прочитать. И всё это одновременно, часто и помногу. Но такое я бы не в постгрес пихал, имея выбор, а в кликхаус какой-нибудь, он для таких задач и сделан.

Хмм... роли-то тут причём? Но то же самое будет и с pg_database, по идее — без толку.