Re: BUG #17916: Expression IN list translates to unqualified operator
От | RekGRpth |
---|---|
Тема | Re: BUG #17916: Expression IN list translates to unqualified operator |
Дата | |
Msg-id | CAPgh2mKwSiwf+Vn57WyKYCjFZedupBEBouFUneUbA3n=6F=pSQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #17916: Expression IN list translates to unqualified operator (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #17916: Expression IN list translates to unqualified operator
|
Список | pgsql-bugs |
Thank you for the clarification. How can I safely use an expression IN list in extensions? with bst regrds, RekGRpth ср, 3 мая 2023 г. в 18:40, Tom Lane <tgl@sss.pgh.pa.us>: > > PG Bug reporting form <noreply@postgresql.org> writes: > > create operator qwe.= (leftarg = char, rightarg = text, function = > > qwe.chartexteq, commutator = operator(qwe.=), hashes, merges); > > set search_path = qwe; > > explain (costs off, verbose on) select i from generate_series(1, 10) i where > > i::char in (2::text); > > > I expected, that IN list translates to pg_catalog.= > > Why would you expect that? It'd make it impossible to use IN > with user-defined data types. In this case, you made an operator > that is a closer match to the given datatypes (ie, "char = text") > than the native "text = text" operator, so it used that one. > > I've not checked the code, but my recollection is that X IN (Y) just > resolves to the same equality operator you'd get by writing X = Y. > There's been some discussion about allowing a schema qualifier to > be included in the syntax, but nothing's been done about that. > > regards, tom lane
В списке pgsql-bugs по дате отправления: