Re: parser that could handle "FROM... SELECT..." as well as "SELECT... FROM..."
Pavel Stehule <[email protected]> Tue, 8 Oct 2019 09:25:21 +0200
| Newsgroups | gmane.comp.db.postgresql.sql |
|---|---|
| Message-ID | <CAFj8pRBh3SNM2KQYYpJ=5u_2xz=5YPoE0-yLVDffoQYsOYuQUg@mail.gmail.com> |
--0000000000006f16d3059461146d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =C3=BAt 8. 10. 2019 v 9:14 odes=C3=ADlatel Marius Andreiana < [email protected]> napsal: > Hi Pavel, > > >> Personally I don't see any benefit of proposed feature - It breaks >> portability of SQL queries (that is not high today). >> > It would be up to each developer which form to use. Some use only > PostgreSQL and don't need portability. > Also, more DBs could parse the new format as well in the future, so this > issue will go away. Need to start somewhere. > I cannot to accept this argument. Lot of developers miss global perspective, and expect what is supported by one database, then all others supports too. Lot of code is created by mistake, and if parser will be tolerant, then this mistake will not be fixed. I don't like a idea, so Postgres is first database that breaks ANSI/SQL. If ANSI/SQL changes syntax, I'll be for it. More, I think so current strict mode is better for readability - every body knows, where can expect some, it is easy and simple. Don't see any reason to change it. --0000000000006f16d3059461146d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">=C3=BAt 8. 10. 2019 v=C2=A09:14 odes= =C3=ADlatel Marius Andreiana <<a href=3D"mailto:[email protected]= om">[email protected]</a>> napsal:<br></div><blockquote class= =3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg= b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr">Hi Pavel= ,</div><div dir=3D"ltr"><br></div><div class=3D"gmail_quote"><blockquote cl= ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid= rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_qu= ote"><div><br></div><div>Personally I don't see any benefit of proposed= feature - It breaks portability of SQL queries (that is not high today).</= div></div></div></blockquote><div>It would be up to each developer which fo= rm to use. Some use only PostgreSQL and don't need portability.</div><d= iv>Also, more DBs could parse the new format as well in the future, so this= issue will go away. Need to start somewhere.</div></div></div></blockquote= ><div><br></div><div>I cannot to accept this argument. Lot of developers mi= ss global perspective, and expect what is supported by one database, then a= ll others supports too. Lot of code is created by mistake, and if parser wi= ll be tolerant, then this mistake will not be fixed.<br></div><div><br></di= v><div>I don't like a idea, so Postgres is first database that breaks A= NSI/SQL. If ANSI/SQL changes syntax, I'll be for it. <br></div><div><br= ></div><div>More, I think so current strict mode is better for readability = - every body knows, where can expect some, it is easy and simple. Don't= see any reason to change it.</div><div><br></div><div><br></div><div><br><= /div></div></div> --0000000000006f16d3059461146d--