Re: [HACKERS] plpgsql - additional extra checks

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: [HACKERS] plpgsql - additional extra checks
Дата
Msg-id c46bf7fc-e0e5-f8f7-ad69-92b171204cfc@BlueTreble.com
обсуждение исходный текст
Ответ на [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  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: [HACKERS] plpgsql - additional extra checks  (Marko Tiikkaja <marko@joh.to>)
Список 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 по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: [HACKERS] WIP: [[Parallel] Shared] Hash
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: [HACKERS] Proposal for changes to recovery.conf API