qwwqэто невыразимо печально.

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

ещё один налетел на отсутствие ByRef в plpgsql (и, видимо, вообще во всех plpg вызовах, тут не уверен).

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

не тушкой, так чучелком, не в plpg так в каком-нть другом новоязе, обзовите его Pl/sql, что ли....

Не истины ради, а флуда для...

Вот фига впихивать не впихуемое.
Если нужна какая-то логика не влазящая в РМД, то вынесите ее в любой удобный ЯП.
Благо PostgreSQL позволяет писать ХП почти на любом используемом ЯП.

А лучше, вообще, вынести в слой приложения...

О срачь!

qwwqа мцжики и не знают. В оракуле, например.
даже презренные ара--калоеды соблаговолили реализовать передачу по ссылкам в своем грёбанном Pl/sql (не без последствий и грабелек, но да)


Это естественно для Oracle, они пихают в свою СУБД всякое дерьмо, что потом для развертывания и поддерживания этого фрянкинпуха нужна туева хуча сертфицированных специалистов.

qwwqа Post, простите, грессовцы -- как аборигены на пальмах с интерпретаторами -- ничего кроме передачи по значению так и ниасилили.


Ибо не фиг!
Нужны извратные ХП.
Извольте писать их на нормальных ЯП.
C, Python, Java и пр.

И вообще нативные ХП для PostgreSQL пишутся на SQL.
PlPgSQL это просто внешний ЯП, кое-как эмулирующий работу plSql.
Причем его надо подключать точно так же, как и, например, Perl. (PlPerl)

А так голимый SQL и никакой императивщины!

qwwqесли гроб с музыкой -- про данные -- он должен быть в слое данных. т.е. в СУБД.


Если что-то нельзя выразить через "отношения", то нафиг это из СУРБД.
Для этого есть более удобные инструменты.

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


Ого у вас в данных есть логика?!
Мне всегда казалось, что данные это просто данные.

А логика появляется при работе с данными.

Данные хранятся в БД.
А логика работы с данными описывается в ЯП.

Или у вас данные знают как себя обрабатывать?! :-)

qwwqmad_nazgul,

check , validation , exclusion , reference , constraint , unique

-- это наверное дятлы от непонимания в рсубд понатащили
, ага, ага


При чем тут это?
Вполне нормальный декларативный подход.
А вот всякик, if, while, for и пр.
Нафиг, нафиг из СУРБД.

qwwqиди в "сравнении" языком полощи, злобнобуратинец керов

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


Данные, это просто данные.
А вот что с этими данными делать должно решать приложение.
РМД очень простая и ограниченная модель.
Поэтому и были придуманы разные plsql и tsql.
Чтобы выйти за рамки РМД.

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


Потому что PostgreSQL не работает в рамках императивного подхода.
Возможность работы с различными ЯП, это костыль, т.е. РМД ограничена и не покрывает всего многообразия мира.

Кроме того "не реализует результаты ч/з ссылку" это правильно, т.к. ХП могут использоваться не только в запросе, но и в других ХП, написанных на других ЯП.

В общем идеологически PostgreSQL более выдержан.
Хотя из-за этого "удобства" программирования меньше.