Re: Change JOIN tutorial to focus more on explicit joins

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Jürgen Purtz <juergen(at)purtz(dot)de>
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-22 15:14:19
Message-ID: CAFj8pRBEFAq_8EMy1btfUAzfvLOa_9-h8vYwzcAh1V_ufqykVw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs pgsql-hackers

čt 22. 10. 2020 v 15:32 odesílatel Jürgen Purtz <juergen(at)purtz(dot)de> napsal:

> On 22.10.20 01:40, David G. Johnston wrote:
>
> On Fri, Sep 4, 2020 at 2:36 AM Jürgen Purtz <juergen(at)purtz(dot)de> wrote:
>
>> On 04.09.20 08:52, Peter Eisentraut wrote:
>> >
>> > For the remaining patch I have a couple of concerns:
>>
>
> This patch should not be changing the formatting choices for these
> queries, just the addition of a JOIN clause and modification of the WHERE
> clause. Specifically, SELECT is left-aligned while all subsequent clauses
> indent under it. Forced alignment by adding extra spaces isn't done here
> either. I have not altered those in the attached.
>
> Did some word-smithing on the first paragraph. The part about the
> cross-join was hurt by "in some way" and "may be" is not needed.
>
> Pointing out that values from both tables doesn't seem like an improvement
> when the second item covers that and it is more specific in noting that the
> city name that is joined on appears twice - once from each table.
>
> ON expression is more precise and the reader should be ok with the term.
>
> Removal of the exercise is good. Not the time to discuss cross join
> anyway. Given that "ON true" works the cross join form isn't even required.
>
> In the FROM clause form I would not add table prefixes to the column
> names. They are not part of the form changing. If discussion about table
> prefixing is desired it should be done explicitly and by itself. They are
> used later on, I didn't check to see whether that was covered or might be
> confusing.
>
> I suggested a wording for why to use join syntax that doesn't involve
> legacy and points out its merit compared to sticking a join expression into
> the where clause.
>
> The original patch missed having the syntax for the first left outer join
> conform to the multi-line query writing standard you introduced. I did not
> change.
>
> The "AND" ON clause should just go with (not changed):
>
> ON (w1.temp_lo < w2.temp_lo
> AND w1.temp_hi > w2.temp_high);
>
> Attaching my suggestions made on top of the attached original
> 0002-query.patch
>
> David J.
>
> (Hopefully) I have integrated all of David's suggestions as well as the
> following rules:
>
> - Syntax formatting with the previously used 4 spaces plus newline for JOIN
>
> - Table aliases only when necessary or explicitly discussed
>
> The discussion about the explicit vs. implicit syntax is added to the "As
> join expressions serve a specific purpose ... " sentence and creates a
> paragraph of its own.
>
> The patch is build on top of master.
>

Why do you use parenthesis for ON clause? It is useless. SQL is not C or
JAVA.

Regards

Pavel

--
> J. Purtz
>
>
>

In response to

Responses

Browse pgsql-docs by date

  From Date Subject
Next Message David G. Johnston 2020-10-22 16:27:08 Re: Change JOIN tutorial to focus more on explicit joins
Previous Message Jürgen Purtz 2020-10-22 13:32:00 Re: Change JOIN tutorial to focus more on explicit joins

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Dilger 2020-10-22 16:01:00 Re: new heapcheck contrib module
Previous Message Dilip Kumar 2020-10-22 15:06:48 Re: Is Recovery actually paused?