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

From: Marko Tiikkaja <marko(at)joh(dot)to>
To: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Joel Jacobson <joel(at)trustly(dot)com>
Subject: Improving PL/PgSQL (was: Re: plpgsql defensive mode)
Date: 2014-09-06 18:08:40
Message-ID: 540B4DA8.7010107@joh.to
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2014-09-06 7:56 PM, Pavel Stehule wrote:
> 2014-09-06 19:54 GMT+02:00 Marko Tiikkaja <marko(at)joh(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-09-06 18:24:58 Re: Allowing implicit 'text' -> xml|json|jsonb
Previous Message Pavel Stehule 2014-09-06 18:01:55 Re: proposal: plpgsql - Assert statement