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

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.
>

I use some fragments of this routine. But the problem was so I did implicit
unnesting, although plpgsql doesn't do this

https://github.com/okbob/plpgsql_check/commit/c06c9e3dbf175c8d7d5b1df20e01dc3fea339281

postgres=# create or replace function broken_into()
returns void as $$
declare v typ2;
begin
-- should to fail
select (10,20)::typ2 into v;
-- should be ok
select ((10,20)::typ2).* into v;
-- should to fail
execute 'select (10,20)::typ2' into v;
-- should be ok
execute 'select ((10,20)::typ2).*' into v;
end;
$$ language plpgsql;
CREATE FUNCTION
postgres=# select * from plpgsql_check_function('broken_into', fatal_errors
=> false);
┌────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ plpgsql_check_function
│
╞════════════════════════════════════════════════════════════════════════════════════════════════════════════╡
│ error:42804:5:SQL statement:cannot cast composite value of "typ2" type to
a scalar value of "integer" type │
│ warning:00000:5:SQL statement:too few attributes for composite variable
│
│ error:42804:9:EXECUTE:cannot cast composite value of "typ2" type to a
scalar value of "integer" type │
│ warning:00000:9:EXECUTE:too few attributes for composite variable
│
│ warning extra:00000:2:DECLARE:never read variable "v"
│
└────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
(5 rows)

Regards

Pavel

> In the meantime, it does seem like the docs could be more explicit
> about this, and perhaps give an example showing the (x).* solution.
>
> regards, tom lane
>