A common misconception (that SQL is a realization of RA instead of barely based on it).

In RA, is in fact `Relation > Operator`

https://cs186berkeley.net/notes/note6/

https://web.wlu.ca/science/physcomp/ikotsireas/CP465/W1-Intr...

https://home.adelphi.edu/~siegfried/cs443/443l9.pdf

Okay, so what?

We're not obligated to emulate the notational norms of our source material, and it is often bad to do so when context changes.

[0]: https://github.com/postgres/postgres/tree/master/src/backend...

Lots of people “like” things because they are familiar with them. And that’s a fine enough reason. But if you step out of your zone of familiarity, can you find improvements? Are you willing to forgo any prejudice you may possess to evaluate other suggestions?

Just a little willingness to see another perspective is all anyone asks.

Funnily enough, if you pull up a version of Postgres' parser prior to the 1995 release, you'll find that it puts the relation first.

No one was confused what you were doing.

I'm saying the historical reason for why it is the way it is, doesn't matter. I would hope we design our languages to be maximally clear and useful, not to be maximally full of historical cruft.

There's no accounting for taste, so you're welcome to like whatever you like, but I don't think you liking a backward syntax is particularly persuasive. It sounds more like you're just used to it than that you see any actual benefits to it.

It's inspired by a mish-mash of both relational algebra and relational calculus, but the reason why SELECT comes first is because authors wanted it to read like English (it was originally called Structured English Query Language).

You can write the relational algebra operators in any order you want to get the result you want.

Ultimately, yes, you can express relational algebra in any notation that gets the point across, but the parent is right that

   π₁(R)

   (R)π₁

Π(σ(R)) instead of σ(Π(R))

and not about whether relational algebra uses prefix or postfix notation:

Π(σ(R)) vs. R > σ > Π

SQL's WHERE statement (and others) works totally differently from SELECT in that regard, so it doesn't make much sense to say that "SELECT comes first because relational algebra".

I don’t think I see what you see. From 3.3:

    RANGE PART P
    GET W (P.P#,P.PNAME,P.QOH):(P.QOH<25)

   SELECT p.pnum, p.pname, p.qoh FROM part p WHERE p.qoh < 25

   FROM part p SELECT p.pnum, p.pname, p.qoh WHERE p.qoh < 25

   FROM part p; SELECT p.pnum, p.pname, p.qoh WHERE p.qoh < 25

More likely because this order is closer to typical English sentence structure. SQL was designed to look like English, not relational algebra.

Except this works in most major vendor SQL implementations. And they all support relation aliases in SELECT... Seems the standards have long fell behind actual implementations.

    SELECT id AS foo
    FROM MyTable
    WHERE foo = 1;

    SELECT id
    FROM MyTable
    WHERE id = MAX(id);

You can of course alias columns for SELECT however you’d like, and can also use those aliases in ORDER BY. You can also trivially refactor the above examples to use subqueries or CTEs to accomplish the goal.

    SELECT LOWER(Name) as LName FROM Product where LName like '%frame%';

You can also use "correlated column aliases" (I can't recall the proper name) i.e.

    SELECT
        id AS foo,
        foo || '_1' as foo_n,
        right(foo_n, 1) as foo_ordinal
    FROM MyTable
    WHERE foo = 1;

Don't blame the math for sloppy implementation. Nothing in the math suggest where aliases should be specified. Don't get me wrong it is a coinvent, logical place to put them, but as you say it rather limits their use, and could have been done better.