Paul Ramsey <[email protected]> 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
