> However, as of 7.4, that problem is gone too. If you write the function
> just as above (language sql, volatile, not strict) then the planner will
> inline it and indeed what you get is a CASE. Watch this:
Hm. I wonder if there are cases of people using functions like this with
user-defined volatile functions depending on the function's side effects
happening the correct number of times. Or do volatile functions not get
inlined like this?
> So we do actually have a sort-of-credible way to make a user-defined
> function that emulates IF(). I think we might be able to do Oracle's
> DECODE() as well, though I don't know its exact definition. (You'd
> still need to make several of 'em to handle differing numbers of
> arguments, but that seems well within the bounds of feasibility.)
I think there's a problem implementing decode() surrounding NULL:
SELECT decode(col, 'foo', 1, NULL, 2, 3)
would mean:
SELECT CASE WHEN col='foo' THEN 1
WHEN col IS NULL THEN 2
ELSE 3
END
To do it I think you would need a iseq() function that compared NULLs as being
equal.
--
greg
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
