Did you ever not do things like

  select name, min(price) from product join product_price on product.id = product_price.product_id

where you start with "I need a product name and minimum price" before thinking about where they come from?

The more one uses SQL to filter for, the more you'll think about what you want to achieve vs how (which comes after): in a sense, the SELECT is your function return type declaration, and I frequently start my functions with the declaration.

> where you start with "I need a product name and minimum price" before thinking about where they come from?

Sure, and pretty much every time the names I wrote up were not the ones in the table so that was a complete waste of time.

> the SELECT is your function return type declaration

That might be true if “select” only contained aliases, bur that’s not the case at all, so what it is is complete nonsense.

This presumes that you never pick the wrong table, as well? :D

My argument would be largely that you are doing a search of all of the tables for the columns that you want. With having to know the way to join the necessary tables along the way.

And I want to be clear, I don't think this is necessarily "the way." I more think that it is almost certainly an iterative process that can be started at either place, and will require bouncing between the two quite often.

For instance, yes, you can autocomplete column names from tables that you have put in the from. What if you can't find the column you are anticipating there? Go back and rescan the table names hoping you can guess which table should have the column you want? Then go back to autocomplete for columns to see if expected value appears? Or go to a bit more of a global search for columns?

Either way should be fine.

Nope.