Re: Types pollution with iso-8859-1 oids and server-side parameters binding
От | Tom Lane |
---|---|
Тема | Re: Types pollution with iso-8859-1 oids and server-side parameters binding |
Дата | |
Msg-id | 2189979.1651607722@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Types pollution with iso-8859-1 oids and server-side parameters binding (Daniele Varrazzo <daniele.varrazzo@gmail.com>) |
Ответы |
Re: Types pollution with iso-8859-1 oids and server-side parameters binding
Re: Types pollution with iso-8859-1 oids and server-side parameters binding |
Список | pgsql-bugs |
Daniele Varrazzo <daniele.varrazzo@gmail.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
В списке pgsql-bugs по дате отправления: