Comments 14
Нельзя использовать в логической репликации.
Что это означает?
Таблица с таким столбцом не будет реплицироваться?
Столбец не будет реплицироваться? Но зачем, если он вычислимый на стороне приемника репликации.
Нельзя индексировать.
То, что их нельзя индексировать, выглядит как-то ну очень глупо неочевидно. Индексированный виртуальный или хранимый - в чём разница, кроме места хранения?
Нельзя изменять выражение (ALTER TABLE… DROP EXPRESSION).
ALTER TABLE… DROP EXPRESSION - это не изменение выражения. Это изменение типа поля - с вычисляемого на статическое.
в чём разница, кроме места хранения?
тоже удивился. Ведь по выраженияем в pg можно индексы делать, почему по выражениям, описанным в колонке нельзя. Видимо просто не допилили пока что.
Вот именно. По сути вся разница в том, что выражение переносится из метаданных индекса в метаданные таблицы, и ему присваивается имя, трактуемое как имя поля. А все остальные проблемы по сути уже решены.
В пг так яростно пилят некоторые фичи, что зачастую получается откровенное говно не пригодное к использованию. С виртуальными колонками выходит именно так. Мы их запилили, но использовать их Вы мало где сможете. У меня закономерный вопрос - а нахрена такое пилить?
поправлю про drop expression
Я можно кейс из реальной жизни - зачем ?
Тупой пример - это влияние по общим правилам нескольких полей в одно поле, ФИО, например.
Раньше это решалось через создание view с доп калькулируемым столбцом. Но текущее решение ничего нового чего давало view не имеет. Поэтому и выглядит странным.
Собственно по сравнению с представлением единственный плюс вычисляемого поля - это возможность его индексировать. Но именно этой фичи и не реализовано.
И, насколько я понимаю, не реализована ещё одна фича вычисляемого поля, которая очень нужна, если таковое поле вводится в структуру уже эксплуатируемой таблицы - возможность сделать такое поле скрытым (INVISIBLE). При отсутствии подобной фичи поломается много кода, особенно неаккуратно написанного кода - такого, где выполняются COPY/INSERT без указания списка полей. Да и SELECT *, опять же без списка конкретных полей, поплывёт, если где-то используется позиционная обработка или привязка структуры отображения к структуре полученного набора.
Это все очень интересно, но вот подскажите знатоки.
Как при установке в windows posgresql-installer.exe --locale указать американскую локализацию, мне нужно автоматизировать этот процесс и я написал маленький скрипт на плюсах, но самый принципиальный параметр локализация никак. En срабатывает корректно, а как выбрать именно американскую en_us, кстати такое написание, как и en_us.utf.8, "en_us.utf8", и все прочие вариации не срабатывает. В документации написано ini-file, пишет мол не правильно указываешь параметр.
Простите за оффтоп, но просто крик души.
Virtual generated columns в PostgreSQL 18