Comment by tomtheelder
4 years ago
> Where in here is it clearly stated which fields are returned? In the original SQL it's right up front but here it's buried into the "aggregate" function, and I'm not clear that this isn't an oversight.
It's in the aggregate portion, like you said. Other example queries have a select portion. Why does it matter that it's not in the leading position like SQL?
> Does this mean that the database must scan all records of the employee table in order to return the result before moving to the next step in the query? Must I index all fields? If not, how does a query planner prepare for this scenario?
No, they are just describing how the statement is supposed to be interpreted by a human. I think you can basically just shuffle all the filter statements to the end and keep it logically equivalent.
This is a proposal for a "transpiles to SQL" language. So long as that transpliation is predictable, you cannot run into the sort of issues you are describing.
> It's in the aggregate portion, like you said. Other example queries have a select portion. Why does it matter that it's not in the leading position like SQL?
I don't mind it not being in the leading position. The author provided a very simple query and in that case it's not immediately apparent what fields to expect the resultset to contain when returned to the consumer.
This is a troubleshooting issue more than anything else. IMO placing the "selected fields" into the very centre of the query is distracting and obfuscates what is happening.
> This is a proposal for a "transpiles to SQL" language. So long as that transpliation is predictable, you cannot run into the sort of issues you are describing.
I think a good test of whether any transpiled language works well is to look at whether it could work on its own as a language. See: Typescript.