From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [GENERAL] Needed function IF(expr, expr, expr) |
Date: | 2003-09-07 23:00:03 |
Message-ID: | 87llt06w7g.fsf@stark.dyndns.tv |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Rod Taylor | 2003-09-07 23:25:30 | Re: Needed function IF(expr, expr, expr) |
Previous Message | Andreas Pflug | 2003-09-07 21:34:45 | Re: Unixware 713 probs |
From | Date | Subject | |
---|---|---|---|
Next Message | Jenny - | 2003-09-07 23:07:42 | Re: table-level and row-level locks. |
Previous Message | Bruce Momjian | 2003-09-07 22:26:00 | Re: [HACKERS] Index creation takes for ever |