Re: plpgsql - additional extra checks

2017-09-13 1:42 GMT+02:00 Daniel Gustafsson <daniel(at)yesql(dot)se>:

> > 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 2cd70845240087da205695baedab64
> 12342d1dbe
> to compile. Changing to using TupleDescAttr(); makes it compile again.
> Can
> you submit an updated version with that fix Pavel?
>

I am sending fixed patch

Regards

Pavel

>
> Stephen, you signed up to review this patch in the previous Commitfest, do
> you
> still intend to work on this?
>
> cheers ./daniel