Re: Example query causing param_info to be set in plain rel path

No adding OFFSET there too didn't give the expected result. The lateral was
handled in subquery and passed as param to the underlying table scan.

I am particularly interested in tables (unlike functions or subqueries)
since, the table scans are shipped to the datanodes and I wanted to test
the effect of lateral in such cases. OTH, functions involving access to the
tables or subqueries are initiated on the coordinators, where lateral gets
executed in the same way as PostgreSQL.

If it's so hard to come up with an example query which would cause
lateral_relids to be set in RelOptInfo of a table, then it's very likely
that relevant code is untested in PostgreSQL.

On Fri, Oct 25, 2013 at 7:11 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> writes:
> > In order to test various cases of LATERAL join in Postgres-XC, I am
> trying
> > to find a query where RelOptInof->lateral_relids would get set for plain
> > base relations.
>
> I think you need a lateral reference in a function or VALUES FROM-item.
> As you say, plain sub-selects are likely to get flattened. (Possibly
> if you stuck in a flattening fence such as OFFSET 0, you could get the
> case to happen with a sub-select FROM item, but I'm too lazy to check.)
>
> regards, tom lane
>

--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company