Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I'm expecting coerce_type to fail, along the lines of
> ERROR: failed to find conversion function from unknown to whatever
OK. After playing with that and reading the code in more depth, I now
see what you've been saying.
[picks up lance and takes aim at windmill]
It still seems solvable without getting too extreme.
It seems to me that all of the conditional expressions besides the
ones using the CASE keyword *could* be resolved down to a literal of
unknown type at parse time, since they fall into this behavior *only*
when all parameters are NULL or literals of unknown type. Behavior
would be deterministic at parse time. The biggest argument against
doing this is that it would be bad to have behavior for the CASE
abbreviations which doesn't match the behavior of the CASE predicate
itself. Less trivial than what I thought was needed, but doable.
[spurs donkey to a trot]
I think the explicit CASE predicate can be solved, too.
The thing which makes the CASE predicate harder, is that you can have
the information that the result is guaranteed to be NULL or an untyped
literal, but you might not know *which* of the values will be chosen
until run time. (I don't know why it took me this long to see that
distinction. Oh, well.) We currently coerce all of the return values
to text for this. OK. But...
[breaks into a gallop]
... you know that it *will* be a NULL or a literal of unknown type,
and at parse time you can determine *which* typinput function will
need to be used once the actual value is determined at run time.
[reaches windmill]
So, couldn't the plan just include something to call the typinput at
run time against the text value we're already building up?
[brushes dust from clothing]
What did I miss this time?
-Kevin