Re: PL/pgSQL: Spurious 22P02 error on "select col into var" when col is user-defined type

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bryn Llewellyn <bryn(at)yugabyte(dot)com>, pgsql-general list <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: PL/pgSQL: Spurious 22P02 error on "select col into var" when col is user-defined type
Date: 2021-08-10 05:05:57
Message-ID: CAFj8pRBn6yEb1EZY3N=-KLfXWVpx9FBCvL_YKMBK91wWKjjjYA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

po 9. 8. 2021 v 23:13 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napsal:

> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> > Some errors like this, but not this can be detected by plpgsql_check
> > https://github.com/okbob/plpgsql_check - probably the heuristic for type
> > check is not complete.
>
> STRICTMULTIASSIGNMENT would detect most cases of this, except that
> the condition is checked too late. We'd need to count the fields
> *before* trying to assign values, not after.
>
> In the meantime, it does seem like the docs could be more explicit
> about this, and perhaps give an example showing the (x).* solution.
>

Yes, a more detailed explanation of this behavior can be nice. There can
be an example of value unnesting, but I think so for this case, there
should be mainly an example of ANSI assign syntax.

var := (SELECT x FROM ..)

This syntax has advantages so is not amigonuous for this case, and explicit
unnesting is not necessary (and it is not possible). Moreover, this is ANSI
SQL syntax.

Regards

Pavel

> regards, tom lane
>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Pavel Stehule 2021-08-10 05:23:11 Re: PL/pgSQL: Spurious 22P02 error on "select col into var" when col is user-defined type
Previous Message Mladen Gogala 2021-08-10 03:18:46 Re: Serious List of PostgreSQL usage questions.