On Sun, Mar 28, 2021, at 13:51, Pavel Stehule wrote:
There were some similar tools already. Personally I like the current state, where tables should be explicitly defined, and join should be explicitly defined. The joining of tables is not cheap - and I like the visibility of this. On the other hand, this is very frustrable for a lot of people, and I can understand. I don't want to see this feature inside Postgres, because it can reduce the possibility to detect badly written query. But it can be a great feature of some outer tool. I worked for GoodData and this tool knows the model, and it generates necessary joins implicitly, and people like it (this tool uses Postgres too).
Very good points.
As a counter-argument, I could argue that you don't need to use this feature.
But that would be a poor argument, since you might have to work with code
written by other developers.
I'm also fearful of newbies misusing features, not understanding what they are doing, producing inefficient code.
However, this is a general problem, complex queries are hard to reason about,
and I'm not sure making some INNER JOINs implicit would worsen the situation,
you could also make the counter-argument that the remaining explicit JOINs become more visible,
and will stand-out, exposing what is really complex in the query.
Also, this proposed syntax would surely appeal to the NoSQL-crowd,
and should reduce their cravings for MongoDB.
So ask yourself the following question: Ten years from now, would you rather be forced to
work with code using MongoDB or a more concise SQL?
Lastly, let me reiterate I think you made a very good point,
your argument is the heaviest weigh on the negative side of my own scale.
/Joel