Re: [HACKERS] merging some features from plpgsql2 project

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: [HACKERS] merging some features from plpgsql2 project
Дата
Msg-id CAFj8pRDvmK8S_NWR9Zkm4mSqpjCdVnfy4E=rCQL=wR0nPoABVg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] merging some features from plpgsql2 project  (Merlin Moncure <mmoncure@gmail.com>)
Ответы Re: [HACKERS] merging some features from plpgsql2 project
Список pgsql-hackers
Дерево обсуждения


2017-01-11 20:53 GMT+01:00 Merlin Moncure <mmoncure@gmail.com>:
On Wed, Jan 11, 2017 at 11:11 AM, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
> The current syntax was chosen because it is SQL-compatible.  Adding
> redundant syntax to save a few characters without any new functionality
> (performance, resource usage, safety, etc.) is a weak argument in the
> overall scheme of things.

Yeah -- exactly.  The few minor things that are not 100% SQL
compatible I find to be major headaches.  Incompatible usage of INTO
for example.

We not designed INTO usage in plpgsql - it is PL/SQL heritage.

PL/SQL = ADA + Oracle SQL; -- but sometimes the result is not perfect - Ada was not designed be integrated with SQL
 

This thread has been going on for quite some time now and is starting
to become somewhat circular.   Perhaps we ought to organize the
various ideas and pain points presented in a wiki along with
conclusions, and in some cases if there is no solution that is
compatible with the current syntax.

There is a language that is much better integrated with SQL - SQL/PSM

http://postgres.cz/wiki/SQL/PSM_Manual

It is less verbose, but still verbose language. It is static typed language - so it can be bad for some people.

But due design based on SQL integration from base, there is less conflicts between SQL and PL.

Regards

Pavel


merlin

В списке pgsql-hackers по дате отправления: