Antonin Houska <antonin.houska@gmail.com> writes:
> On 05/22/2012 09:31 PM, Robert Haas wrote:
>> 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?
Well, it's not per spec: what you did accepts queries that are invalid
per spec and are very likely to be errors rather than intentional
invocations of the LATERAL facility. This might be all right for
experimental playing around, but there is zero chance that we will
commit it that way.
Quite aside from the error-detection issue, I would think that we would
want explicit LATERAL JOIN syntax which we'd turn into join order
restrictions (cf SpecialJoinInfo), so that the planner need not waste
time searching join orders that can't possibly work because of the
presence of the parameter references. This situation is unlike the
standard nestloop-with-parameterized-inner-scan case, because in that
case the parameterized path is merely one option of many. With a
LATERAL reference, there are no other implementation options.
> 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.
Quite honestly, I think that something that only handles functions as
LATERAL righthands is broken by design. It doesn't meet the spec, and
it's unlikely to represent much of a step towards a full implementation.
Remember Polya's Inventor's Paradox: the more general problem may be
easier to solve.
regards, tom lane