Re: Allowing extensions to supply operator-/function-specific info

Paul Ramsey <pramsey(at)cleverelephant(dot)ca> writes:
> The documentation says that a support function should have a signature "supportfn(internal) returns internal”, but doesn’t say which (if any) annotations should be provided. IMMUTABLE? PARALLEL SAFE? STRICT? None? All?

It doesn't matter much given that these things aren't callable from SQL.
The builtin ones are marked immutable/safe/strict, but that's mostly
because that's the default state for builtin functions. The only one
I'd get excited about is marking it strict if you're not going to check
for a null argument ... and even that is neatnik-ism, not something that
will have any practical effect.

> Variable SupportRequestCost is very exciting, but given that variable cost is usually driven by the complexity of arguments, what kind of argument is the SupportRequestCost call fed during the planning stage? Constant arguments are pretty straight forward, but what gets sent in when a column is one (or all) of the arguments?

You'll see whatever is in the post-constant-folding parse tree. If it's a
Const, you can look at the value. If it's a Var, you could perhaps look
at the pg_statistic info for that column, though whether that would give
you much of a leg up for cost estimation is hard to say. For any sort of
expression, you're probably going to be reduced to using a default
estimate. The core code generally doesn't try to be intelligent about
anything beyond the Const and Var cases.

regards, tom lane