Re: COALESCE implementation question

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Philip Warner <pjw(at)rhyme(dot)com(dot)au>
Cc: pgsql-hackers(at)hub(dot)org
Subject: Re: COALESCE implementation question
Date: 2000-08-06 03:28:08
Message-ID: 18581.965532488@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Philip Warner <pjw(at)rhyme(dot)com(dot)au> writes:
>> Well, the standard is perfectly clear, isn't it? If V(1) has side
>> effects then trying to optimize this into just one evaluation of V(1)
>> will generate non-spec-compliant results.

> At least with the new function manager, if I feel te need I can write a
> 'CoalesceValues' function (at least for fixed numbers of parameters).

Mmm ... not really. You could detect nulls all right, but a function-
based version of COALESCE would evaluate *all* its arguments exactly
once, which is certainly wrong. If you don't stop evaluating with
the one you decide to return, you are neither compliant with the spec
nor safe (later expressions might yield errors if evaluated!)

> Sadly, my usual yard stick (Dec/RDB) seems to evaluate twice (at least
> that's what it's planner says). And dumping a view with a coalesce
> statement produces a CASE statement, so it probably has no choice.

Sounds like they do it the same as we do, ie, expand COALESCE into the
specified CASE equivalent on sight.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Lockhart 2000-08-06 03:45:57 Re: LIKE/ESCAPE implementation
Previous Message Philip Warner 2000-08-06 03:23:29 Re: COALESCE implementation question