-
Notifications
You must be signed in to change notification settings - Fork 3.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sql: variables within generator expressions aren't resolved properly #13156
Comments
This problem seems a bit tricky to resolve. It may require rethinking how generator expressions should work, and its solution may be tied into whatever we end up doing to support correlated subqueries. The trouble is that if a data source expression contains a reference to a column, the data source must be "evaluated" once per row. Currently, I believe we assume that data source expressions have no dependent variables and can be evaluated without the context of the rest of the query. The resolution of this issue is a blocker for ActiveRecord. |
This is a lateral correlated sub-query. We don't support that yet. Prioritizing for Q1 2017 is unrealistic. |
We actually don't need the lateral join listed here to work by Q1 - just the simpler form |
After talking with @knz this morning and digging into Postgres's behavior, it seems that supporting set-generating functions in the For posterity, I'm recording my train of thought here. Suppose we see a query like this:
This is broken; table functions in
These are identical queries using alternative syntaxes for
unless you make it a lateral subquery:
So Postgres is implicitly rewriting the
This final form is the only semantically sensible one: i.e., the only one where table functions appear in The point of all this is to say that I don't think there is a simple case here. The "simple" case isn't really simple at all; Postgres just hides the lateral cross join when you specify a table function as a column. |
👍 |
Probably we should fix this panic before 1.0. @benesch didn't you have an almost finished patch for this? Can we clean it up enough to submit and prevent the crash at least? |
Yup, #14369 just needs a bit more work. |
@benesch how does this sound now? Is there any chance your PR will land for 1.0? Otherwise we can just slip to 1.1 or later. |
Give it another look, @knz! :) |
#14369 landed! Updating the milestone to 1.1, since the panic is resolved. |
Similar-looking report from @HeikoOnnebrink. today I was prototyping some SQL as part of some REST API. HeikoOnnebrink @HeikoOnnebrink 07:14
|
Hmm, that looks unrelated at a first glance. I don't see any generator expressions in that query. |
Please file a separate issue if needed. |
My guess is the |
No, doing so now. |
Punting this back to @jordanlewis, since I did my part for 1.0. 😀 |
Suppose we have the following table definition:
The following query works in Postgres, but fails in CockroachDB with
column name "id" not found
.Specifying the table name doesn't help either. The following query fails with
source name "a" not found in FROM clause
:And in related news, attempting to issue this kind of query via the render list as per the resolution of #13140 produces a panic:
The text was updated successfully, but these errors were encountered: