Improving PL/PgSQL (was: Re: plpgsql defensive mode)

Поиск
Список
Период
Сортировка
От Marko Tiikkaja
Тема Improving PL/PgSQL (was: Re: plpgsql defensive mode)
Дата
Msg-id 540B4DA8.7010107@joh.to
обсуждение исходный текст
Ответ на Re: plpgsql defensive mode  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: Improving PL/PgSQL  (Jan Wieck <jan@wi3ck.info>)
Re: Improving PL/PgSQL (was: Re: plpgsql defensive mode)  (Pavel Stehule <pavel.stehule@gmail.com>)
Список pgsql-hackers
On 2014-09-06 7:56 PM, Pavel Stehule wrote:
> 2014-09-06 19:54 GMT+02:00 Marko Tiikkaja <marko@joh.to>:
>> Then that doesn't really solve our problem.  Switching between two
>> languages on a per-function basis, when both look exactly the same but have
>> very different semantics would be a nightmare.
>>
>
> It is maximum what is possible
>
> use a different language instead

Sigh.

OK, let's try and forget the cardinality assertions we've been talking 
about in the other thread(s).  I seem to recall there being a generally 
welcoming atmosphere in the discussion about adding a set of pragmas (or 
options/whatever) to make some of PL/PgSQL's flaws go away, in a 
non-backwards compatible way.  From the list here: 
https://wiki.postgresql.org/wiki/Improving_PL/PgSQL_(September_2014) do 
you think at least some of those would be reasonable candidates for 
these pragmas?  Do you see others ones that are missing from this list?

Please also keep discussion about ASSERT in the thread for that, and the 
suggestion under "Single-row operations" out of this.


.marko



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

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: proposal: plpgsql - Assert statement
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Allowing implicit 'text' -> xml|json|jsonb