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
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 |