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

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

2014-09-06 21:47 GMT+02:00 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:

>
>
>
> 2014-09-06 20:08 GMT+02:00 Marko Tiikkaja <marko(at)joh(dot)to>:
>
>> 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.
>>
>
> SELECT .. INTO vs. TOO_MANY_ROWS
>
> +1 .. possible every where
>
correction +1 .. in defensive mode due compatibility issues.

> Variable assignments
>
> +1 .. only in "defensive mode"
> Single-row operations
>
> +1 .. only in "defensive mode" without special syntax
> EXECUTE and FOUND
>
> -1 .. it is emulation of PL/SQL behave.. so introduction can do too high
> unhappy surprise if somebody will migrate to Oracle -- the syntax is too
> similar
> OUT parameters
>
> -1 .. to proposal .. It is in contradiction with current feature. Next it
> is nonsense. INTO clause should to contains only plpgsql variables - in 9.x
> Postgres there is not possible issue.
> postgres=# create table x(a int, b int);
> CREATE TABLE
> postgres=# insert into x values(10,20);
> INSERT 0 1
> postgres=# create or replace function foo(out a int, out b int)
> postgres-# returns record as $$
> postgres$# begin
> postgres$# select x.a, x.b from x into a, b;
> postgres$# return;
> postgres$# end;
> postgres$# $$ language plpgsql;
> CREATE FUNCTION
> postgres=# select * from foo();
> a | b
> ----+----
> 10 | 20
> (1 row)
>
>
> you can see, there is not any collision
> Assertions
>
> -1 to proposed syntax - I wrote about my reasons in other thread.
>
> Regards
>
> Pavel
>
>
>
>>
>> .marko
>>
>
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2014-09-07 04:55:39 Re: Adding a nullable DOMAIN column w/ CHECK
Previous Message Tom Lane 2014-09-07 03:40:02 Re: Patch for psql History Display on MacOSX