From: | Jürgen Purtz <juergen(at)purtz(dot)de> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Thomas Kellerer <shammat(at)gmx(dot)net>, Pg Docs <pgsql-docs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Change JOIN tutorial to focus more on explicit joins |
Date: | 2020-10-23 09:14:07 |
Message-ID: | 81d5be9d-aa6f-f181-bea9-5a852b876cad@purtz.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs pgsql-hackers |
On 22.10.20 17:14, Pavel Stehule wrote:
>
> Why do you use parenthesis for ON clause? It is useless. SQL is not C
> or JAVA.
Two more general answers:
- Why do people use tabs, spaces, and newlines to format their code even
though it's not necessary? SQL is a language to develop applications.
And what are the main costs of an application? It's not the time which
it takes to develop them. It's the time for their maintenance. During
the course of one or more decades, different persons will have to read
the code, add additional features, and fix bugs. They need some time to
read and understand the existing code. This task can be accelerated if
the code is easy to read. Therefore, it's a good habit of developers to
sometimes spend some extra characters to the code than is required -
not only comments. An example: there are clear precedence rules for
Boolean operators NOT/AND/OR. In an extensive statement it may be
helpful - for the developer himself as well as for anybody else -to use
newlines and parentheses at places where they are not necessary to keep
an overview of the intention of the statement. In such cases,
code-optimization is the duty of the compiler, not of the developer.
- In my professional life as a software developer, I have seen about 15
different languages. But only in rare cases, they have offered new
features or concepts. To overcome this Babylonian linguistic diversity I
tend to use such syntactical constructs which are common to many of them
even, even if they are not necessary for the concrete language.
And the concrete answer: Omitting the parentheses for the join condition
raises the danger that its Boolean operators are mixed with the Boolean
operators of the WHERE condition. The result at runtime is the same, but
a reader will understand the intention of the statement faster if the
parentheses exists.
--
J. Purtz
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2020-10-23 09:23:04 | Re: Change JOIN tutorial to focus more on explicit joins |
Previous Message | Pavel Stehule | 2020-10-22 16:31:07 | Re: Change JOIN tutorial to focus more on explicit joins |
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2020-10-23 09:23:04 | Re: Change JOIN tutorial to focus more on explicit joins |
Previous Message | Michael Paquier | 2020-10-23 09:06:30 | Re: Online checksums verification in the backend |