Moin Tom, On Mon, February 12, 2018 5:03 pm, Tom Lane wrote: > Pavel Stehule <pavel.steh...@gmail.com> writes: >> 2018-02-09 12:02 GMT+01:00 Marko Tiikkaja <ma...@joh.to>: >>> This is quite short-sighted. The better way to do this is to complain >>> if >>> the number of expressions is different from the number of target >>> variables >>> (and the target variable is not a record-ish type). There's been at >>> least >>> two patches for this earlier (one my me, and one by, I think Pavel >>> Stehule). I urge you to dig around in the archives to avoid wasting >>> your >>> time. [snip a bit]
> As things stand today, we would have a hard time tightening that up > without producing unwanted complaints about the cases mentioned in > this comment, because the DTYPE_ROW logic is used for both "INTO a,b,c" > and composite-type variables. However, my pending patch at > https://commitfest.postgresql.org/17/1439/ > gets rid of the use of DTYPE_ROW for composite types, and once that > is in it might well be reasonable to just throw a flat-out error for > wrong number of source values for a DTYPE_ROW target. I can't > immediately think of any good reason why you'd want to allow for > the number of INTO items not matching what the query produces. Perl lets you set a fixed number of multiple variables from an array and discard the rest like so: my ($a, $b) = (1,2,3); and the right hand side can also be a function: my ($c, $d) = somefunc( 123 ); Where somefunc() returns more than 2 params. This is quite handy if you sometimes need more ore less return values, but don't want to create almost-identical functions for each case. I'm not sure if you mean exactly the scenario as in the attached test case, but this works in plpgsql, too, and would be a shame to lose. OTOH, one could also write: SELECT INTO ba, bb a,b FROM foo(1); and it would still work, or wouldn't it? Best regards, Tels
test.psql
Description: Binary data
test.pl
Description: Perl program