Re: SupportRequestSimplify and SQL SRF

Ronan Dunklau <ronan_dunklau(at)ultimatesoftware(dot)com> writes:
> What I want to do is to evaluate whether id = t1_id AND somecolumn is NOT
> NULL at planification time, and replace the function by another one if this
> can be pruned altogether.

Hm. There was never really any expectation that support functions
would be attached to PL functions --- since you have to write the
former in C, it seems a little odd for the supported function not
to also be C. Perhaps more to the point though, what simplification
knowledge is this support function bringing to bear that the planner
hasn't already got? It kinda feels like you are trying to solve
this in the wrong place.

> So, what I've been doing is to implement a support function for
> SupportRequestSimplify, and If the predicate doesn't match any row, replace
> the FuncExpr by a new one, calling a different function.

I'm confused. I don't see any SupportRequestSimplify call at all in the
code path for set-returning functions. Maybe there should be one,
but there is not.

> This seems to work great, but I have several questions:

> 1) Is it valid to make SPI calls in a support function to do this kind of
> simplification ?

Hmm, a bit scary maybe but we don't hesitate to const-simplify
functions that could contain SPI calls, so I don't see a big
problem in that aspect. I'd be more worried, if you're executing
some random SQL that way, about whether the SQL reliably does what
you want (in the face of variable search_path and the like).

> 2) My new FuncExpr doesn't get inlined. This is because in
> inline_set_returning_function, we check that after the call to
> eval_const_expressions we still call the same function.

Uh, what? I didn't check the back branches, but I see nothing
remotely like that in HEAD.

regards, tom lane