Почему в постгресе нету переменных типа DECLARE @var INTEGER; SET

@var = 5;
...

все что я нагуглил так это юзать WITH, но оно же иммутабельное после выборки так сказать. А как решаются вопросы переиспользования значения выборки? Наверное одну и ту же выборку делать на одно значение еще норм, а для большинства юзают наверное TEMPORARY TABLE?

чем плох plpgsql?

Вообще, в БОЛЬШЫНСТВЕ случаев это не требуется. Ты один раз кинул запрос, получил данные — всё, жуй в клиенте, радуйся что дали и не нагружай сервер данными, которые ты ужэ от него получил. А в меньшынстве — да, можно temporary tables использовать, можно и не-temporary (если оно должно жыть дольшэ этой сэссии).

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

а в чем собственно проблема? можно например объявить курсор и работать с ним

ну в скл сервере я могу выборку хранить в переменной, поюзать ее, потом изменить ее в ходе какого-то CASE, IF и переиспользовать, крч удобно. Тут как?

не очень понимаю задачу, но курсор подойдет?

Если хотите спуститься к императивному программированию, используйте pl/pgsql.

ваув, то есть как в доке написано, перед бегином идут декларации вариаблей, а в бегине уже тело функции, плюс оборачивается все в plpgsql. А популярно использование функций и процедур? CREATE FUNCTION sales_tax(subtotal real) RETURNS real AS $$ BEGIN RETURN subtotal * 0.06; END; $$ LANGUAGE plpgsql;

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

Создать временную таблицу и не мучатся

От проекта очень сильно зависит. Где-то лишь в исключительных случаях прибегают к хранимкам (тут без относительно языка: их можно писать не только на pl/pgsql, но у последнего в плане синтаксиса - безбарьерная интеграция с sql, так что если нужно писать много запросов - он более удобен), в других может быть пол системы на них написано, зависит от имеющихся разработчиков, которых можно взять в проект.

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

Какая разница где искать казалось бы 😃

Бизнес никогда не заставляет этого делать, это делают сами

Это потому, что ты незнаешь SQL, незнаешь языка хранимок, не знаешь принцыпов РСУБД и слегка плаваешь в программировании вообще. Ну да, если читать написанное на незнакомом инструменте без большого опыта — будет получаться с переменным успехом.

что?

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

(Пожав плечами) Все там были.

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

Так вам про это и написали)))) ну не ваш стэк что тут страшного

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

нет.

да 🤷🏼‍♂️ просто надо хорошо знать плпгскл, а не на уровне "ну я же знаю crud в майскл, разберусь как-нибудь"

чем отдельная команда разработчиков под pl/sql лучше отдельной команды <подставте ЯП который вам нравиться>?

Не лучше и не хуже Нужно две для нормального enterprise

Тем, что к pl/sql требуется ещё Oracle ) А это добавляет плюс 100 к энтерпрайзности

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

Эм а plpgsql не?

можно попробовать, там наверняка есть аддон для этого

Оно туда сюда конвертируется сейчас почти без затрат

Ну, это ведь не PL/SQL. Хотя и сделан по образу и безобразию.

хм, но я видела неимоверную кучу вакансий по конвертации одного в другое

Ada и modula наше все ;)

Еслиб. PL/I всё-таки. (Полной реализацыи которого так никто и ниасилил сделать).

Конечно, это нормально - с обоих сторон надо приводить к «стандарту»

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

дай бог

Не, plsql чистая Ada (modula) , plpgsql наследник

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

Да конечно

а ты с хранимкой дб свитчни.

зачем?

Только что-то я нифига не вижу в PL/* информативных закрывающих скобок...

а тестики ты как писать будешь на свою бизнес логику в хранимочке?😊

Ящик Пандоры открываете. Есть тулзы для написания тестов для хранимок. Правда хз как все это в ci/cd затаскивали

Ящик Пандоры это?

буду, и пишу, на тестовой базе

Как пишешь то?

Как обычно: деплой/подхват тэстового окружэния, создание предопределённых условий, вызов хранимки с известным результатом, сравнение результата.

Ну это все очень круто, а как понять в каком именно месте что-то пошло ни так? Добавлять как сказал товарищ сверху, рейз нотисы?

Конечно. (Как будто в каких-то других местах есть сильно другие вменяемые способы отладки, кроме организацыи и снятия трасс выполнения).

Просто ни в одной из процедур с которыми работаю нету ни логирования, ни хотя бы комментов над каждым кте объясняя какую прикладную функцию он делает. Ну Оке, на будущее буду знать как делать.

Это очевидно зависит от ЯП. Для java мира всё здесь изложенное неверно, для .NET скорее всего тоже, для js - скорее всего верно.

Начинай писать юнит-тэсты (их там, думаю, тожэ нет — а жызнь они облегчают сильно).

Да в любом языке можно просто брать драйвер и роу скл писать себе динамическое и кайфовать, так что тейк не 100% верен, но ТК бизнесу надо быстро, то да, орм и прочие вещи везде юзаются.

Каким образом юнит тест на процедуру в 2к строк написать? Типа вызов, сверение с ожидаемым результатом? Такое себе чёт по полезности)

Декомпозиция? Грешно? Хотя и 2к строк не так много, если там просто огромные запросы и парочка условий. Эти же 2к будут на любом другом языке, какая разница то.

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

Если тебе это некомфортно — разбей на куски по 30 строчек.

Если что, под pl/pgsql есть дебаггер, можете пошагово пройтись и посмотреть, что там происходит на уровне переменных