From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | arthur(dot)mcgibbon(at)gmail(dot)com |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #17631: Prepare + Merge fails to identify parameter types |
Date: | 2022-10-10 20:53:28 |
Message-ID: | 151679.1665435208@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> create table foo (id int, bar bit);
> PREPARE foo_merge as
> merge into foo as target
> using(values($1, $2))
> as source (id, bar)
> on target.id = source.id
> when matched then
> update set bar = source.bar
> when not matched then
> insert(id, bar)
> values ($1, $2);
> gives error...
> ERROR: operator does not exist: integer = text
> LINE 5: on target.id = source.id
> ^
> HINT: No operator matches the given name and argument types. You might need
> to add explicit type casts.
I don't see any bug here. There's no reason to assume that the VALUES
clause in USING must yield the same columns that the merge target table
has, so those Params just default to text type. I realize that there
are some kluges that let "insert into foo values($1,$2)" act differently,
but the key word there is "kluge". VALUES in contexts other than INSERT
has never had such a behavior. For example, if you do this:
prepare foo as select * from foo join (values($1,$2)) v(f1,f2) on id = v.f1;
you'll get the very same failure:
ERROR: operator does not exist: integer = text
LINE 1: ...elect * from foo join (values($1,$2)) v(f1,f2) on id = v.f1;
^
HINT: No operator matches the given name and argument types. You might need to add explicit type casts.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | PG Bug reporting form | 2022-10-11 02:33:34 | BUG #17632: a potential bug of memory leak |
Previous Message | PG Bug reporting form | 2022-10-10 17:14:34 | BUG #17631: Prepare + Merge fails to identify parameter types |