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

From Jim Nasby
Subject Re: [HACKERS] plpgsql - additional extra checks
Date
Msg-id c46bf7fc-e0e5-f8f7-ad69-92b171204cfc@BlueTreble.com
Whole thread Raw
In response to [HACKERS] plpgsql - additional extra checks  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: [HACKERS] plpgsql - additional extra checks  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: [HACKERS] plpgsql - additional extra checks  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: [HACKERS] plpgsql - additional extra checks  (Marko Tiikkaja <marko@joh.to>)
List pgsql-hackers
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.

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 by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: [HACKERS] WIP: [[Parallel] Shared] Hash
Next
From: Fujii Masao
Date:
Subject: Re: [HACKERS] Proposal for changes to recovery.conf API