Earlier quoted context omitted.
Am I right in thinking that this does not increase Postgres's expressive power but allows more concise implementation?
No, you can write queries that are not really possible to express without it. Basically, it allows you to execute a table-valued function for each row in an earlier query. For example, in SQL Server I find a common use of CROSS APPLY (which appears to be the same thing) is where the "table-valued function" is a SELECT with a WHERE clause referencing the earlier query, an ORDER BY, and a TOP (=LIMIT) 1. (In fact, this…
PostgreSQL’s New LATERAL Join Type
11–20 of 42 posts
Re: PostgreSQL’s New LATERAL Join Type
#12"Loosely, it means that a LATERAL join is like a SQL foreach loop, in which PostgreSQL will iterate over each row in a result set and evaluate a subquery using that row as a parameter."
Re: PostgreSQL’s New LATERAL Join Type
#13Re: PostgreSQL’s New LATERAL Join Type
#14As someone who only works now and then with Postgres, this is what made it click for me: "Loosely, it means that a LATERAL join is like a SQL foreach loop, in which PostgreSQL will iterate over each row in a result set and evaluate a subquery using that row as a parameter."
Re: PostgreSQL’s New LATERAL Join Type
#15Earlier quoted context omitted.
Am I right in thinking that this does not increase Postgres's expressive power but allows more concise implementation?
No, you can write queries that are not really possible to express without it. Basically, it allows you to execute a table-valued function for each row in an earlier query. For example, in SQL Server I find a common use of CROSS APPLY (which appears to be the same thing) is where the "table-valued function" is a SELECT with a WHERE clause referencing the earlier query, an ORDER BY, and a TOP (=LIMIT) 1. (In fact, this…
Re: PostgreSQL’s New LATERAL Join Type
#16As someone who only works now and then with Postgres, this is what made it click for me: "Loosely, it means that a LATERAL join is like a SQL foreach loop, in which PostgreSQL will iterate over each row in a result set and evaluate a subquery using that row as a parameter."
Sounds like what Oracle calls a "correlated subquery" is it the same thing?
SELECT *
FROM employees e
WHERE EXISTS (SELECT 1
FROM employee_projects ep
WHERE ep.employee_id = e.id
AND ep.project_id = 5)
;
This new feature is a lot like correlated subqueries except you can put that nested SELECT into the FROM clause and still access the employees table.Re: PostgreSQL’s New LATERAL Join Type
#17Earlier quoted context omitted.
No, you can write queries that are not really possible to express without it. Basically, it allows you to execute a table-valued function for each row in an earlier query. For example, in SQL Server I find a common use of CROSS APPLY (which appears to be the same thing) is where the "table-valued function" is a SELECT with a WHERE clause referencing the earlier query, an ORDER BY, and a TOP (=LIMIT) 1. (In fact, this…
That's not true. Anything you can do with LATERAL you can also do with correlated scalar subqueries in the SELECT list. LATERAL simply makes writing these kinds of queries easier and more intuitive.
Re: PostgreSQL’s New LATERAL Join Type
#18Earlier quoted context omitted.
That's not true. Anything you can do with LATERAL you can also do with correlated scalar subqueries in the SELECT list. LATERAL simply makes writing these kinds of queries easier and more intuitive.
The syntax for this is pretty horrible, however. And if you want to return more than one column from the subquery, you would have to duplicate the subquery definition for each column, right? Then you'd have to have faith that the optimizer can work out what you meant and reconstruct just a single subquery.
Re: PostgreSQL’s New LATERAL Join Type
#19Re: PostgreSQL’s New LATERAL Join Type
#20i.e.
SELECT a, (SELECT b FROM ...) b FROM ....