Re: extra function calls from query returning composite type

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.

In response to

Browse pgsql-general by date

  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