Re: Improving PL/PgSQL - Mailing list pgsql-hackers

From Marko Tiikkaja
Subject Re: Improving PL/PgSQL
Date
Msg-id 540C7D17.5040509@joh.to
Whole thread Raw
In response to Re: Improving PL/PgSQL (was: Re: plpgsql defensive mode)  (Pavel Stehule <pavel.stehule@gmail.com>)
List 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



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Final Patch for GROUPING SETS - unrecognized node type: 347
Next
From: Emre Hasegeli
Date:
Subject: Re: Selectivity estimation for inet operators