Re: POC, WIP: OR-clause support for indexes

On Fri, Oct 4, 2024 at 9:40 PM Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, Oct 4, 2024 at 2:20 PM Peter Geoghegan <pg@bowt.ie> wrote:
> > On Fri, Oct 4, 2024 at 2:00 PM Alexander Korotkov <aekorotkov@gmail.com> wrote:
> > > Yes, transformAExprIn() does the work to coerce all the expressions in
> > > the right part to the same type.  Similar logic could be implemented
> > > in match_orclause_to_indexcol().  What worries me is whether it's
> > > quite late stage for this kind of work.  transformAExprIn() works
> > > during parse stage, when we need to to resolve types, operators etc.
> > > And we do that once.
> >
> > I agree that it would be a bit awkward. Especially having spent so
> > much time talking about doing this later on, not during parsing. That
> > doesn't mean that it's necessarily the wrong thing to do, though.
>
> True, but we also can't realistically use select_common_type() here. I
> mean, it thinks that we have a ParseState and that there might be
> values with type UNKNOWNOID floating around. By the time we reach the
> planner, neither thing is true. And honestly, it looks to me like
> that's pointing to a deeper problem with your idea. When someone
> writes foo IN (1, 2222222222222222222222222), we have to make up our
> mind what type of literal each of those is. select_common_type()
> allows us to decide that since the second value is big, we're going to
> consider both to be literals of type int8. But that is completely
> different than the situation this patch faces. We're now much further
> down the road; we have already decided that, say, 1, is and int4 and
> 2222222222222222222222222 is an int8. It's possible to cast a value to
> a different type if we don't mind failing or have some principled way
> to avoid doing so, but it's way too late to reverse our previous
> decision about how to parse the characters the user entered. The
> original "char *" value is lost to us and the type OID we picked may
> already be stored in the catalogs or something.

+1

------
Regards,
Alexander Korotkov
Supabase