From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "David Johnston" <polobo(at)yahoo(dot)com> |
Cc: | "'Adrian Klaver'" <adrian(dot)klaver(at)gmail(dot)com>, "'jg'" <jg(at)rilk(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Coalesce bug ? |
Date: | 2012-12-21 16:15:53 |
Message-ID: | 16273.1356106553@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"David Johnston" <polobo(at)yahoo(dot)com> writes:
> The first case is:
> SELECT COALESCE( (SELECT), (SELECT) ); I am not sure exactly what the parentheses surrounding the scalar-sub-SELECTs do (turn them into anonymously typed rows?) but if the first scalar-sub-select results in a non-null result then the second one should not be executed.
Indeed, COALESCE will not execute the second sub-select at runtime, but
that doesn't particularly matter here. What matters is that "ps3(2)"
qualifies to be pre-evaluated (folded to a constant) at plan time. So
that happens, and the RAISE message comes out, at plan time. What's
left at run time is
SELECT COALESCE( (SELECT 1), (SELECT 2) );
and indeed the "SELECT 2" is skipped at that point, as is visible in the
EXPLAIN ANALYZE measurements.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David Johnston | 2012-12-21 16:20:02 | Re: Coalesce bug ? |
Previous Message | Chris Angelico | 2012-12-21 16:11:56 | Re: Coalesce bug ? |