Re: Improving PL/PgSQL

From: Marko Tiikkaja <marko(at)joh(dot)to>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Joel Jacobson <joel(at)trustly(dot)com>
Subject: Re: Improving PL/PgSQL
Date: 2014-09-07 15:43:19
Message-ID: 540C7D17.5040509@joh.to
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2014-09-06 9:47 PM, Pavel Stehule wrote:
> -1 .. to proposal .. It is in contradiction with current feature.

Which feature would that be?

> 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

No, not if you do assignments only. But if you also use them as
parameters in plans at some point in the function, there will be collisions.

But I consider that secondary. I think the bigger improvement is that
it's clear what assigning to OUT.foo does when reading the code.

.marko

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Emre Hasegeli 2014-09-07 16:09:39 Re: Selectivity estimation for inet operators
Previous Message Tomas Vondra 2014-09-07 14:14:03 Re: Final Patch for GROUPING SETS - unrecognized node type: 347