From: | David G Johnston <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: extra function calls from query returning composite type |
Date: | 2014-12-31 23:59:53 |
Message-ID: | 1420070393365-5832606.post@n5.nabble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Ronald Peterson wrote
> The existence of LATERAL seems to imply that it's possible.
The presence of LATERAL, which applies during FROM clause processing,
implies nothing about what is possible during SELECT-list processing.
This was a problem for a long time and if an easy/possible solution was
possible without LATERAL it would have been done. LATERAL took a while to
get around to but neatly solves the problem.
I'll agree the being able to write: SELECT col1, col2, func_call(...).*,
col3 for non-set-returning-functions seems to have some value (though such a
function is likely to be defined stable or immutable and so side-steps the
problem - I think) but the most common reason for wanting SELECT
func_call(...) is for a set-returning-function with table-based inputs.
Since your example was set-returning it doesn't add anything to the argument
for not using LATERAL; and there are other problems than just
multiple-evaluation that occur when placing a set-returning-function into
the select-list.
David J.
--
View this message in context: http://postgresql.nabble.com/extra-function-calls-from-query-returning-composite-type-tp5832275p5832606.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2015-01-02 10:59:33 | Re: bdr_init_copy fails when starting 2nd BDR node |
Previous Message | Ronald Peterson | 2014-12-31 23:41:24 | Re: extra function calls from query returning composite type |