From: | RekGRpth <rekgrpth(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #17916: Expression IN list translates to unqualified operator |
Date: | 2023-05-03 13:42:48 |
Message-ID: | CAPgh2mKwSiwf+Vn57WyKYCjFZedupBEBouFUneUbA3n=6F=pSQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)sss(dot)pgh(dot)pa(dot)us>:
>
> PG Bug reporting form <noreply(at)postgresql(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-05-03 13:46:13 | Re: BUG #17917: to_tsquery syntax error |
Previous Message | Tom Lane | 2023-05-03 13:40:44 | Re: BUG #17916: Expression IN list translates to unqualified operator |