On 04.09.20 08:52, Peter Eisentraut wrote:
>
> 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.
>
Ok, but I don't have any better suggestion than to delete this para.
> 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.
In this context, I wouldn't use the terms 'manual' and 'abstract', it's
more about 'implicit' and 'explicit' syntax. The 'explicit' syntax does
not only emphasis the aspect of 'joining' tables, it also differentiates
between the usage of following AND/OR/NOT key words as join conditions
or as additional restrictions (the results are identical but not the
semantic). Because the purpose of this patch is the preference of the
explicit syntax, we shall show this syntax first.
>
> > + <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.
>
Ok, deleted.
--
Jürgen Purtz