Re: BUG #11325: Documentation Bug / RFE - Mailing list pgsql-bugs

From David G Johnston
Subject Re: BUG #11325: Documentation Bug / RFE
Date
Msg-id 1409615655879-5817259.post@n5.nabble.com
Whole thread Raw
In response to Re: BUG #11325: Documentation Bug / RFE  (David G Johnston <david.g.johnston@gmail.com>)
Responses Re: BUG #11325: Documentation Bug / RFE
Re: BUG #11325: Documentation Bug / RFE
List pgsql-bugs
David G Johnston wrote
>
> Tom Lane-2 wrote

>> thomas@

>>  writes:
>>> Two suggestions for "PostgreSQL 9.3.5 Documentation" (which is excellent
>>> in
>>> general, by the way :-)
>>
>>> 1) "Finally, NATURAL is a shorthand form of USING: it forms a USING list
>>> consisting of all column
>>> names that appear in both input tables."
>>> Please clarify: All column names that appear in both input tables
>>> (regardless of the SELECT clause), or all column names /listed in the
>>> SELECT
>>> clause/ that appear in both input tables?
>>
>> "All column names that appear in both input tables" seems perfectly
>> clear to me.  Where would you get the idea that it had something to
>> do with the SELECT list?
>>
>>> 2) "with the exception that if ON is used there will be two columns a,
>>> b,
>>> and c in the result"
>>> Hard to understand. Suggestion:
>>> "if ON is used, each column a, b, and c will appear twice in the
>>> result."
>>
>> Yeah, that's fair, though perhaps it would be better as "each of the
>> columns a, b, and c will appear twice in the result".
> Agree on both counts.
>
> Though the entire "Thus, USING (a,b,c) ..." seems superfluous given the
> subsequent example section.  And given the 'furthermore' aspect of this it
> isn't really "shorthand" for ON but it's own unique mechanic and syntax.
>
> A comment in its own paragraph to the effect:
>
> SELECT * output -
> ON - all columns from T1 followed by all columns from T2
> USING - all join columns, one copy each and in the listed order, followed
> by non-join columns in T1 followed by non-join columns in T2
>
> could be added while removing the "thus" paragraph in USING; as well as
> the concept of shorthand.
>
> David J.

Usage note for USING/NATURAL added as well.




diff --git a/doc/src/sgml/queries.sgml b/doc/src/sgml/queries.sgml
index 9bf3136..c53c2b0 100644
--- a/doc/src/sgml/queries.sgml
+++ b/doc/src/sgml/queries.sgml
@@ -245,25 +245,38 @@ FROM <replaceable>table_reference</replaceable>
<optional>, <replaceable>table_r
         condition: it takes a Boolean value expression of the same
         kind as is used in a <literal>WHERE</> clause.  A pair of rows
         from <replaceable>T1</> and <replaceable>T2</> match if the
-        <literal>ON</> expression evaluates to true for them.
+        <literal>ON</> expression evaluates to true.
        </para>

        <para>
-        <literal>USING</> is a shorthand notation: it takes a
-        comma-separated list of column names, which the joined tables
-        must have in common, and forms a join condition specifying
-        equality of each of these pairs of columns.  Furthermore, the
-        output of <literal>JOIN USING</> has one column for each of
-        the equated pairs of input columns, followed by the
-        remaining columns from each table.  Thus, <literal>USING (a, b,
-        c)</literal> is equivalent to <literal>ON (t1.a = t2.a AND
-        t1.b = t2.b AND t1.c = t2.c)</literal> with the exception that
-        if <literal>ON</> is used there will be two columns
-        <literal>a</>, <literal>b</>, and <literal>c</> in the result,
-        whereas with <literal>USING</> there will be only one of each
-        (and they will appear first if <command>SELECT *</> is used).
+        The <literal>USING</> clause allows you to take advantage of
+        the specific situation where both sides of the join use the
+        same name for the joining columns.  It takes a
+        comma-separated list of the shared column names
+        and forms a join using the equals operator.  Furthermore, the
+        output of <literal>JOIN USING</> has one column for each of the
+        listed columns, followed by the remaining columns from each table.
        </para>

+       <para>The output column difference between <literal>ON</> and
<literal>USING</> when invoking <literal>SELECT *</> is:</para>
+         <itemizedlist>
+          <listitem>
+           <para>
+            <literal>ON</> - all columns from T1 followed by all columns
from T2
+           </para>
+          </listitem>
+          <listitem>
+           <para>
+            <literal>USING</> - all join columns, one copy each and in the
listed order, followed by non-join columns in <replaceable>T1</> followed by
non-join columns in <replaceable>T2</>
+           </para>
+          </listitem>
+          <listitem>
+           <para>
+            Examples provided below
+           </para>
+          </listitem>
+         </itemizedlist>
+
        <para>
         <indexterm>
          <primary>join</primary>
@@ -282,6 +295,16 @@ FROM <replaceable>table_reference</replaceable>
<optional>, <replaceable>table_r
        </para>

        <para>
+        <emphasis>Usage Note:</>
+        <literal>USING</literal> is reasonably safe from column changes
+        in the joined relations since only the specific columns mentioned
+        are considered.  <literal>NATURAL</> is considerably more
problematic
+        if you are referring to relations only by name (views and tables)
+        since any schema changes to either relation that cause a new
matching
+        column name to be present will cause the join to consider that new
column.
+       </para>
+
+       <para>
         The possible types of qualified join are:

        <variablelist>








--
View this message in context:
http://postgresql.1045698.n5.nabble.com/BUG-11325-Documentation-Bug-RFE-tp5817245p5817259.html
Sent from the PostgreSQL - bugs mailing list archive at Nabble.com.

pgsql-bugs by date:

Previous
From: David G Johnston
Date:
Subject: Re: BUG #11325: Documentation Bug / RFE
Next
From: David G Johnston
Date:
Subject: Re: BUG #11325: Documentation Bug / RFE