Re: ERROR: type of parameter 1 (fruit2) does not match that when preparing the plan (fruit1)
| От | David G. Johnston |
|---|---|
| Тема | Re: ERROR: type of parameter 1 (fruit2) does not match that when preparing the plan (fruit1) |
| Дата | |
| Msg-id | CAKFQuwbjOSOxwLPWFrVGd_c3fY8GLsezr7Zs1OpDVN8HRABR1g@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: ERROR: type of parameter 1 (fruit2) does not match that when preparing the plan (fruit1) (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: ERROR: type of parameter 1 (fruit2) does not match that when preparing the plan (fruit1)
|
| Список | pgsql-bugs |
On Sun, May 1, 2022 at 10:08 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Sun, May 1, 2022 at 8:44 AM d <dchuck@yurfish.com> wrote:
>> CREATE OR REPLACE FUNCTION record_to_form_data(p_r record)
> Not a bug, it is a documented limitation.
FWIW, it does seem to work as desired if you declare the argument as
"anyelement".
+1
Maybe we could improve this situation by treating a "record" parameter
as polymorphic, though that might cause some odd inconsistencies with
plpgsql's historical treatment of "record" local variables.
The extent of needing to treat "record" as polymorphic-like seems like it would be limited to resolve_polymorphic_argtype in funcapi.c. Namely, in computing the hash key for the compiled hash entry for the function. Similar to how we append the trigger oid in compute_function_hashkey in pl.compile (which ultimately calls the former) so trigger invocations become per-table.
David J.
В списке pgsql-bugs по дате отправления: