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  ("David G. Johnston" <david.g.johnston@gmail.com>)
Re: Types pollution with iso-8859-1 oids and server-side parameters binding  (Daniele Varrazzo <daniele.varrazzo@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Daniele Varrazzo
Дата:
Сообщение: Types pollution with iso-8859-1 oids and server-side parameters binding
Следующее
От: "David G. Johnston"
Дата:
Сообщение: Re: Types pollution with iso-8859-1 oids and server-side parameters binding