| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com> |
| Cc: | pgsql-bugs <pgsql-bugs(at)postgresql(dot)org> |
| Subject: | Re: Types pollution with unknown oids and server-side parameters binding |
| Date: | 2022-05-03 19:55:22 |
| Message-ID: | 2189979.1651607722@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com> writes:
> A problem shown in https://github.com/psycopg/psycopg/discussions/289
> In the query:
> UPDATE test289 SET num = $1, name = $2, ts = $3 WHERE ts::date = $3::date
> passing a string with unknown oid as param $3 results in the column ts
> receiving only the date part. Looks like the cast needed on the param
> in the WHERE gets propagated to the other occurrences of the same
> parameter.
I think it's operating exactly as designed. The parameter can only
have one type, and the cast is telling it to assume that that type
is "date".
> I see why it happens... I don't think it's the right behaviour though.
What do you think ought to happen? The same parameter somehow having
different types in different places?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David G. Johnston | 2022-05-03 20:31:08 | Re: Types pollution with unknown oids and server-side parameters binding |
| Previous Message | Daniele Varrazzo | 2022-05-03 19:10:20 | Types pollution with unknown oids and server-side parameters binding |