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

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: PL/pgSQL: Spurious 22P02 error on "select col into var" when col is user-defined type
Дата
Msg-id CAFj8pRBn6yEb1EZY3N=-KLfXWVpx9FBCvL_YKMBK91wWKjjjYA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: PL/pgSQL: Spurious 22P02 error on "select col into var" when col is user-defined type  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: PL/pgSQL: Spurious 22P02 error on "select col into var" when col is user-defined type  (Bryn Llewellyn <bryn@yugabyte.com>)
Список pgsql-general


po 9. 8. 2021 v 23:13 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
Pavel Stehule <pavel.stehule@gmail.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

В списке pgsql-general по дате отправления:

Предыдущее
От: Mladen Gogala
Дата:
Сообщение: Re: Serious List of PostgreSQL usage questions.
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: PL/pgSQL: Spurious 22P02 error on "select col into var" when col is user-defined type