Re: plpgsql - additional extra checks

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Marko Tiikkaja <marko(at)joh(dot)to>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, David Steele <david(at)pgmasters(dot)net>
Subject: Re: plpgsql - additional extra checks
Date: 2017-09-12 23:42:28
Message-ID: 6AC20EDF-A8B0-4387-9CED-D389C08F9A0B@yesql.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 08 Apr 2017, at 15:46, David Steele <david(at)pgmasters(dot)net> wrote:
>
>> On 1/13/17 6:55 AM, Marko Tiikkaja wrote:
>>> On Fri, Jan 13, 2017 at 2:46 AM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com
>>> <mailto:Jim(dot)Nasby(at)bluetreble(dot)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.

This patch was automatically marked as “Waiting for author” since it needs to
be updated with the macro changes in 2cd70845240087da205695baedab6412342d1dbe
to compile. Changing to using TupleDescAttr(); makes it compile again. Can
you submit an updated version with that fix Pavel?

Stephen, you signed up to review this patch in the previous Commitfest, do you
still intend to work on this?

cheers ./daniel

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andreas Joseph Krogh 2017-09-12 23:49:02 Re: Clarification in pg10's pgupgrade.html step 10 (upgrading standby servers)
Previous Message Tom Lane 2017-09-12 23:40:24 Re: psql - add special variable to reflect the last query status