b
И это в моём ответе было описано )
Size: a a a
2021 July 05
АС
угу, вы правы
AK
Ребята подскажите кто знает в postgresql 9.6 есть поддержка PL/pgSQL?
СД
ну кстати этот вариант тоже используется: например так у нас хранят историю изменений, само изменение всегда разное и по этой причине лижит в json (там может от одного поля до 10 поменяться в рамках запроса в API)
I
естественно
A
документация точно знает.
VA
Нет. Да и ФИАС уже отживает свое в связи с переходом на ГАР.
A
зы: поддержка 9.6 скоро заканчивается. пора бы уже обновить.
AWS весной всех массово переезжал с 9.6.
AWS весной всех массово переезжал с 9.6.
СД
@batyrmastyr тогда основные варианты использования JSON следующие:
- если есть плавающая структура, которую нельзя быстро и легко вложить в стандартную логику таблиц
- если нет точного понимания насколько долго эти данные сохранят свою структуру (чтобы не делать лишних телодвижений по созданию/обслуживанию таблиц)
верно?
- если есть плавающая структура, которую нельзя быстро и легко вложить в стандартную логику таблиц
- если нет точного понимания насколько долго эти данные сохранят свою структуру (чтобы не делать лишних телодвижений по созданию/обслуживанию таблиц)
верно?
Ю
Это замечательно, только МЧС просит данные именно в ФИАС
AK
тогда вопрос - почему перед запросом я не могу написать декларацию переменных? если есть поддержка
A
b
Наверное лучше обозначить, почему JSON опасен:
1. Вы лишаетесь уверенности, что там лежит именно то, что вы ожидаете. Вы ждёте, что там всегда массив, но кто-то может впендюрить NULL (причём либо SQL NULL, либо JSON null), может бахнуть скаляр или объект. Массив может внезапно стать объектом.
2. Неэффективное хранение. Названия ключей тоже занимают место.
3. Неэффективный поиск.
1. Вы лишаетесь уверенности, что там лежит именно то, что вы ожидаете. Вы ждёте, что там всегда массив, но кто-то может впендюрить NULL (причём либо SQL NULL, либо JSON null), может бахнуть скаляр или объект. Массив может внезапно стать объектом.
2. Неэффективное хранение. Названия ключей тоже занимают место.
3. Неэффективный поиск.
AK
у меня следующая проблема - есть запрос - перед ним я с объявляю переменных - но подсвечиваеся что не верно - например myvar varchar DEFAULT NULL; - переменные нужные для использования в запросе
b
Я бы оставил только первый вариант.
Во втором, при смене структуры, шанс что-то запороть в JSON и заметить это не во время разработки, а через пару дней после выкатки на боевой на порядок больше.
Во втором, при смене структуры, шанс что-то запороть в JSON и заметить это не во время разработки, а через пару дней после выкатки на боевой на порядок больше.
VA
К сожалению, приходиться писать обновляторы фиаса ручками. А с учётом кривизны обновлений придусматривать откат к предыдущим версиям. Путь фиаса это путь боли и скорби.
A
эм... этот запрос в функции или где?
AK
в функции все ок- там все работает; у меня просто запрос селекта с join ами пары таблиц, а выше хотел объявить переменные
A
так а какое отношение pl/pgsql имеет к отдельным запросам?
AK
возможно это отсуствие моего опыта, то есть plsql можно использовать только в рамках функций / процедур?