Support of non-scalar subselects #3568
Replies: 3 comments
-
I would say it's not an immediate priority, and you can of course express this as a join already. What is your use case you need this for? |
Beta Was this translation helpful? Give feedback.
-
Hi @hannes thanks for the response. To be honest, I've never used these in practice and I would probably just re-write it as two scalar subselects, i.e.,
I was more curious from a parsing perspective. I was working on a parser for DuckDB's `SELECT, and using Postgres where I can't find exact examples from DuckDB, just checking if that feature is available in DuckDB or not. Speaking of which, I think it'd be great to have a more formal lexical syntax in the docs, something like: https://cloud.google.com/bigquery/docs/reference/standard-sql/lexical or https://www.postgresql.org/docs/current/sql-syntax.html. Usually when I can't find something I use a combination of Postgres docs and trial-and-error, but I think adding the formal part to the docs would be awesome and help a lot of people. |
Beta Was this translation helpful? Give feedback.
-
Workaround, try this: SELECT * results: Little long hand, aliases matter or in this case I simply employed unique field names. I like the way DuckDB handles, I'll call it shaped data. |
Beta Was this translation helpful? Give feedback.
-
Postgres, Snowflake and a few other DBs support non-scalar subselects, such as:
However in DuckDB it gives a Binder error:
Are there any plans to support this feature? What do you estimate it might take to implement this?
Beta Was this translation helpful? Give feedback.
All reactions