Re: [HACKERS] plpgsql - additional extra checks
От | Pavel Stehule |
---|---|
Тема | Re: [HACKERS] plpgsql - additional extra checks |
Дата | |
Msg-id | CAFj8pRCv0DSwyHX0d1GiADvgC1LELGJ2H_r=RMox_TN_X9mMAw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] plpgsql - additional extra checks (Jim Nasby <Jim.Nasby@BlueTreble.com>) |
Список | pgsql-hackers |
2017-01-13 2:46 GMT+01:00 Jim Nasby <Jim.Nasby@bluetreble.com>:
On 1/11/17 5:54 AM, Pavel Stehule wrote:+ <term><varname>too_many_rows</varname></term>
+ <listitem>
+ <para>
+ When result is assigned to a variable by <literal>INTO</literal> clause,
+ checks if query returns more than one row. In this case the assignment
+ is not deterministic usually - and it can be signal some issues in design.
Shouldn't this also apply to
var := blah FROM some_table WHERE ...;
yes, it is possible.
I am not sure - how to document it. This pattern is undocumented and it is side effect of our parser.
If somebody use var := (SELECT xxx FROM ..)
what is correct syntax, then exactly only one row is required.
But the extra check is ok, if we technically allows this syntax.
Regards
Pavel
?
AIUI that's one of the beefs the plpgsql2 project has.
FWIW, I'd also be in favor of a NOMULTI option to INTO, but I don't see any way to do something like that with var := blah FROM.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)
В списке pgsql-hackers по дате отправления: