[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-general
Subject:    Re: [GENERAL] extra function calls from query returning composite type
From:       David G Johnston <david.g.johnston () gmail ! com>
Date:       2014-12-31 23:59:53
Message-ID: 1420070393365-5832606.post () n5 ! nabble ! com
[Download RAW message or body]

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.


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


[prev in list] [next in list] [prev in thread] [next in thread]