"David Johnston" <[email protected]> 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
--
Sent via pgsql-general mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
