Re: Using scalar function as set-returning: bug or feature?
От | Tom Lane |
---|---|
Тема | Re: Using scalar function as set-returning: bug or feature? |
Дата | |
Msg-id | 30208.1518534140@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Using scalar function as set-returning: bug or feature? ("Tels" <nospam-pg-abuse@bloodgate.com>) |
Список | pgsql-hackers |
"Tels" <nospam-pg-abuse@bloodgate.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
В списке pgsql-hackers по дате отправления: