Tom Lane wrote:
>
> .... (Actually, now
> that I look at it, it looks like the functions rather than the
> operators are missing the necessary preinitialization. Perhaps at
> the place where you chose to put this in, setFcache has already
> been done?)
>
The functions work because the funcid field in the Func node is already
filled in, and the EvalQual code uses this field to generate the Fcache.
In the case of Oper node there are two fields, one for the pg_operator
Oid,
and one for the pg_proc Oid. The pg_operator oid is already filled in,
but the pg_proc oid isn't. The EvalQual code wants the pg_proc oid, so
I provide it in the patch before I do the evaluation.
>
> There are additional smarts that could/should be put in, though. ....
>
> { Many good suggestions here }
>
> .... without adding a flag to pg_proc that tells us if it is OK.
>
All points well taken. I don't have time to do this thoroughly right
now,
but I will get back to it. My original ( needed-for-project-at-hand )
motivation for this was to get index scans to work with expressions that
evaluate to constants. I can see that I am about to learn quite a bit
more about parsing and planning.
> > I puzzled over case of now() for a while but I don't think that it
> > raises a problem.
>
> No, you can't just define the problem away by saying that whatever
> behavior is convenient to implement is acceptable.
Oh darn! -- I've spent too many years studying mathematics
> and user-defined functions could be a problem. SQL functions probably
> shouldn't be folded either (not quite sure of that).
>
> Bruce points out in another reply that the proiscachable field of
> pg_proc is intended for exactly this purpose.
Perhaps adding another option to create function is in order here. I
know how to do that already. Seriously, there are some interesting
semantic issues here, especially if the database were being used as the
basis for a large dynamic stochastic model.
Bernie
