Re: Improving PL/PgSQL

On 09/06/2014 02:08 PM, Marko Tiikkaja wrote:
> 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.

+1 for SELECT INTO throwing TOO_MANY_ROWS if there are more than one.
Zero rows should be dealt with an IF NOT FOUND ... construct.

+1 for the number of result columns should match the expression list of
SELECT INTO.

-1 on removal of implicit type casting. This needs to go into a #pragma
or GUC. Too drastic of a backwards compatibility break.

-1 on the single row operations. This belongs into the main SQL engine
as COMMAND CONSTRAINTS.

+1 on EXECUTE and FOUND, where applicable (DML statements only).

I do not recall why we decided to implement GET DIAGNOSTICS instead of
an automatically set global ROW_COUNT variable. But there was a reason I
believe and we should check the list archives for it.

+1 on the OUT alias.

-1 on the ASSERT as proposed. It would be too easy for application
developers to abuse them to govern business logic and a DBA later
turning off assertions for performance reasons.

Regards,
Jan

--
Jan Wieck
Senior Software Engineer
http://slony.info