On 2020-05-27 10:29, Jürgen Purtz wrote:
> The attached patch
>
> - prefers the explicit join-syntax over the implicit one and explains
> the keywords of the explicit syntax
>
> - uses a more accurate definition of 'join'
>
> - separates <programlisting> and <screen> tags
>
> - shifts <indexterm> definitions outside of <para> to get a better
> rendering in PDF
>
> - adds a note concerning IDs and foreign keys
I have committed some parts of this patch:
> - separates <programlisting> and <screen> tags
> - shifts <indexterm> definitions outside of <para> to get a better
> rendering in PDF
as well as the change of W1/W2 to w1/w2. (Note that there is also
src/tutorial/basics.source that should be adjusted in the same way.)
For the remaining patch I have a couple of concerns:
> <para>
> Attempt to determine the semantics of this query when the
> - <literal>WHERE</literal> clause is omitted.
> + <literal>ON</literal> clause is omitted.
> </para>
> </formalpara>
This no longer works.
In general, I agree that some more emphasis on the JOIN syntax is okay.
But I think the order in which the tutorial has taught it so far is
okay: First you do it the manual way, then you learn the more abstract way.
> + <note>
> + <para>
> + The examples shown here combine rows via city names.
> + This should help to understand the concept. Professional
> + solutions prefer to use numerical IDs and foreign keys
> + to join tables.
> + </para>
> + </note>
While there are interesting debates to be had about natural vs.
surrogate keys, I don't think we should imply that one of them is
unprofessional and then leave it at that and give no further guidance.
I think we should leave this out.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services