Tom Lane <t...@sss.pgh.pa.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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
