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

From David Steele
Subject Re: [HACKERS] plpgsql - additional extra checks
Date
Msg-id 32526c99-21bb-7073-44d1-31be2aba43bb@pgmasters.net
Whole thread Raw
In response to Re: [HACKERS] plpgsql - additional extra checks  (Marko Tiikkaja <marko@joh.to>)
Responses Re: [HACKERS] plpgsql - additional extra checks  (David Steele <david@pgmasters.net>)
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 patch still applies cleanly and compiles at cccbdde.

-- 
-David
david@pgmasters.net



pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: [HACKERS] Re: [PATCH] guc-ify the formerly hard-coded MAX_SEND_SIZE tomax_wal_send
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] Partition-wise join for join between (declaratively)partitioned tables