Re: Changing SQL Inlining Behaviour (or...?)

Further question about this ...

I'm thinking about exactly when indxpath.c should interrogate extensions'
planner support functions. Since it'll cost some cycles to look up and
call such functions, we don't want to do it if there's little or no chance
of getting an index match. Currently, what match_clause_to_indexcol()
does first for an operator clause is to see if match_index_to_operand()
succeeds for either operator input; if so it investigates more closely,
if not it ignores the clause. I'm thinking of maintaining that rule
for operators and adding the same rule for function clauses appearing
in WHERE. Therefore, an extension would only have the opportunity to
add a lossy index clause when some argument of its function or operator
is the same Var or expression that is indexed. Is that going to be
sufficient, or are there weird cases where an index condition could
be built but none of the top-level function or operator inputs
exactly match the index column?

The cases you've shown us, where you transform a function with
argument x into an indexable operator with the same argument x
as the potentially-indexed side, don't look like they'd have any
trouble with that restriction. But I'm worried that maybe I'm
missing something.

regards, tom lane