On 05/22/2012 09:31 PM, Robert Haas wrote:
This implementation looks different than I'd expect: I would have
thought that it would work by generating paths with param_info set to
the appropriate set of rels to provide the necessary values, rather
than inventing its own mechanism for forcing a nestloop.
My consideration was something like: clauses are responsible for the
fact that parameter info is path-specific. However function parameters
have little to do with clauses, so they should be treated rather
separate, at higher level than that of individual paths.
Looking at the code again, I admit there's yet no strong reason not to
use the existing 'parameterization infrastructure'. I'll try to think up
something better.
Also, I think we will want something that implements the LATERAL()
syntax, rather than just removing the prohibition on lateral references.
So you think it's not good to first implement (implicitly) lateral
functions and add the explicit LATERAL() operator later, when the
optimizer can handle lateral subqueries too? (explicit LATERAL() that
only can take function as the argument and not subquery sounds weird).
I personally need the lateral functions much more than lateral
subqueries, but I have no impression of the attitude of (majority of)
other users.
While I believe I'm (slowly though) approaching a viable concept of
lateral functions, it's quite clear to me that the lateral subqueries
are obviously a bigger challenge.
These are both the reasons why I started to think about the functions
as a separate patch.
Tony H.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
