From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Tels" <nospam-pg-abuse(at)bloodgate(dot)com> |
Cc: | "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>, "Marko Tiikkaja" <marko(at)joh(dot)to>, "Konstantin Knizhnik" <k(dot)knizhnik(at)postgrespro(dot)ru>, "PostgreSQL Hackers" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Using scalar function as set-returning: bug or feature? |
Date: | 2018-02-13 15:02:20 |
Message-ID: | 30208.1518534140@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Tels" <nospam-pg-abuse(at)bloodgate(dot)com> writes:
> On Mon, February 12, 2018 5:03 pm, Tom Lane wrote:
>> ... 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);
> 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.
Well, that's exactly the issue. Whether that's a handy feature or
a foot-gun that hides bugs depends entirely on your point of view.
Personally, this is not the kind of behavior I really want from a
programming language ;-). And I'm sure that if plpgsql were still
enforcing the old rules, and someone came along with a proposal to
relax that to be more like Perl, it'd be laughed down.
Still, backwards compatibility is worth something. I don't really
have a strong opinion about whether to change it or not.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Udit Juneja | 2018-02-13 15:40:31 | [GSoC Idea Discussion] "Thrift datatype support" Project |
Previous Message | Alvaro Herrera | 2018-02-13 14:40:01 | Re: [Sender Address Forgery]Re: [Sender Address Forgery]Re: [Sender Address Forgery]Re: [HACKERS] path toward faster partition pruning |