Re: [PG19] Bogus errors for polymorphic plpython functions

shihao zhong <zhong950419(at)gmail(dot)com> writes:
> Did a quick test, I think it worked on master

> CREATE FUNCTION r3(OUT r record)
> AS $$ return (1, 2) $$ LANGUAGE plpython3u;
> SELECT * FROM r3() AS (a int, b int);
> SELECT * FROM r3();

Ah, good point. I was thinking about the general case,
which doesn't really work:

regression=# CREATE FUNCTION multiout_record(INOUT n integer, OUT record) AS $$
return (n, (n * 2, n * 3))
$$ LANGUAGE plpython3u;
CREATE FUNCTION
regression=# SELECT * FROM multiout_record(2);
ERROR: record type has not been registered
CONTEXT: while creating return value
PL/Python function "multiout_record"

But with just one "OUT record" parameter, that's equivalent to
"RETURNS record", so it should work. This is showing us another
omission in plpython's regression tests :-(

After sleeping on it, I've decided that while moving these checks into
the validator is a good idea, it's not the most appropriate way to fix
this in v19. That is, I now think that this is really funccache.c's
bug not plpython's: it should be on funccache.c to not fail in this
situation. Yesterday I'd been dithering over whether external users
of funccache.c might want the existing behavior, but I can't see how
it'd be useful to them. Validators subject to this issue would have
to construct fake fcinfos that are much more complete than what we've
expected so far.

So here's a v2 patch series. 0001 fixes the immediate problem by
teaching funccache.c to not fail, and I envision back-patching that
to v19 or maybe even v18. Then 0002 rearranges plpython's validator,
but I now think that should go to master only. It does cause a user-
visible behavioral change (tighter checking with check_function_bodies
off), and we should refrain from unnecessary changes of that kind
post-rc1.

regards, tom lane