Добрый день, а может кто-нибудь подсказать, где почитать про различия

в параметре LANGUAGE при создании функции - напишу я там sql или plpgsql? Пытаюсь перевести хранимку с MS SQL на постгрес, а что-то то одна ошибка, то другая, и какие-то неоднозначные...

там указывается на каком языке будет написана хранимая функция

Это я понял, спасибо)) Просто например мне нужно внутри этой функции объявить переменные и создать временные таблицы. И я не совсем понимаю, что и как я могу делать, а что нет. Например, в блоке begin-end я вроде бы не могу декларировать переменные и темповые таблицы, а где тогда их объявлять, если я указываю language sql?

если вы указали plpgsql то можете делать что позволяет его синртаксис, если sql То только sql

но если я указываю sql и тупо копирую хранимку из MS SQL, то у меня ничего не работает) Получается, этот sql какой-то определенный, не такой как MS...

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

а есть какой-нить туториал по переносу с перечислением всех таких важных моментов?) Не первый же я столкнулся с этой задачей по переносу...

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

Рабочего -- нет, только хорошо изучить оба языка. Потом можно идти по чеклистам и бест практиз -- но без изучения обоих диалектов SQL это достаточно безсмысленно.

https://wiki.postgresql.org/wiki/Converting_from_other_Databases_to_PostgreSQL#Microsoft_SQL_Server

большое спасибо!) Половина ссылок из этого списка уже фиолетовые, но я забыл, что вообще этот список находил, надо еще раз все перечитать)

в SQL Server язык написания хранимок - T-SQL, а не чистый SQL, именно поэтому вы можете в нем использовать переменные, циклы и тд. В Postgres ближайшим аналогом T-SQL является plpgsql. Чистый SQL не поддерживает императивных конструкций. Процедуры/функции/вьюхи, которые не используют императивный мусор, перенесутся простой копипастой с минимальными изменениями, а все императивное нужно будет портировать на plpgsql, иногда не совсем тривиально. Я недавно занимался ровно таким проектом, пишите если будут конкретные вопросы

👍Благодарю!

вот этот материал оказался полезен для того чтоб начать https://severalnines.com/database-blog/migrating-mssql-postgresql-what-you-should-know

Да еще стоит отметит что бездумный порт T-SQL в plpgsql плохой вариант, у меня количество процедур уменьшилось на треть при том что функциональность кода существенно выросла при переходе с MS SQL на PostgreSQL.

👍

Ради интереса, т.к. сам подобным занимался - а зачем переезжали? Просто в моём случае, что-то стало лучше, а что-то хуже.

Переезжали так как было желание перевести движок на open source, я потратил много времени на анализ различных СУБД остановился на PostgreSQL о выборе не жалею. Что лучше что хуже написать можно но это был бы радикально длинный пост. даже не знаю...

поста совсем не прошу, т.к. представляю, что могло быть ) пришлось переписать с T-SQL кучу кода несколько лет назад интересны были именно причины желание иметь open source вполне всё объясняет

в моем случае были сложности с сертификацией oracle UPD: увидел что речь шла не о нем

мало знаю про оракл, если честно но слышал мнение, что 95% кода переносимо прямо копипастом

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

С копипастом я наткнулся на неадекватное падание производительности при использовании скалярных функция, которые в исходном решении меня не беспокоили в этом отношении. (ЗЫ: MS SQL)

тут такая ещё штука, в которую стукнулся - линукс тюнить надо много больше с MS SQL - скорее приходилось узнавать про СХД и файловые системы, т.к. упиралось, как правило, всё-таки в это, в олтп постгрес тоже не лишён оного, но как-то, субъективно, всё-таки, поменьше

на этом консалтеры и аутсорсеры и зарабатывают, имхо

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

тут тоже соглашусь - чем прямее (как рельс), тем проще, что дебажить, что разбираться, где именно проблема

Именно для программиста БД — PostgreSQL [куда] более "продвинут", удобен, да и логичен. А вот как "затаскивают" сюда DBA, я не знаю. ;)

А могли бы не отказываться, кстати: https://wiki.postgresql.org/wiki/Inlining_of_SQL_functions ;)

Да я это видел в том числе, спасибо.

Дмитрий Иванов
Только сейчас нашлась минутка, ну да лучше поздно ...

Just saying: не всякую функцию, которая "только выбирает данные", можно объявлять STABLE, т.е. лучше прочитать документацию при параметры.