Re: [HACKERS] plpgsql - additional extra checks - Mailing list pgsql-hackers

From David Steele
Subject Re: [HACKERS] plpgsql - additional extra checks
Date
Msg-id 3e3d3427-3aca-3f3f-9dd9-ba575733c42e@pgmasters.net
Whole thread Raw
In response to Re: [HACKERS] plpgsql - additional extra checks  (David Steele <david@pgmasters.net>)
Responses Re: [HACKERS] plpgsql - additional extra checks  (Daniel Gustafsson <daniel@yesql.se>)
List pgsql-hackers
> On 1/13/17 6:55 AM, Marko Tiikkaja wrote:
>> On Fri, Jan 13, 2017 at 2:46 AM, Jim Nasby <Jim.Nasby@bluetreble.com
>> <mailto:Jim.Nasby@bluetreble.com>> wrote:
>>
>>     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 ...;
>>
>>     ?
>>
>>     AIUI that's one of the beefs the plpgsql2 project has.
>>
>>
>> No, not at all.  That syntax is undocumented and only works because
>> PL/PgSQL is a hack internally.  We don't use it, and frankly I don't
>> think anyone should.

This submission has been moved to CF 2017-07.

-- 
-David
david@pgmasters.net



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: [HACKERS] recent deadlock regression test failures
Next
From: David Steele
Date:
Subject: Re: [HACKERS] Making clausesel.c Smarter