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

From David G Johnston
Subject Re: BUG #11325: Documentation Bug / RFE
Date
Msg-id CAKFQuwZRB19GGru8JucKqLi5sMEruU=6py2ruVTSr0J==gjT=Q@mail.gmail.com
Whole thread Raw
In response to Re: BUG #11325: Documentation Bug / RFE  (David G Johnston <david.g.johnston@gmail.com>)
List pgsql-bugs
Converted the usage note to an actual <note> tag and added a couple of
missing <replaceable> tags for T1 and T2

David J.

diff --git a/doc/src/sgml/queries.sgml b/doc/src/sgml/queries.sgml
index 9bf3136..e640d29 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 <replaceable>T1</> followed
by all columns from <replaceable>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>
@@ -281,6 +294,17 @@ FROM <replaceable>table_reference</replaceable>
<optional>, <replaceable>table_r
         <literal>CROSS JOIN</literal>.
        </para>

+       <note>
+        <para>
+         <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>
+       </note>
+
        <para>
         The possible types of qualified join are:




On Mon, Sep 1, 2014 at 7:54 PM, David G Johnston [via PostgreSQL] <
ml-node+s1045698n5817259h53@n5.nabble.com> wrote:

>  David G Johnston wrote
>
> Tom Lane-2 wrote
> [hidden email] <http://user/SendEmail.jtp?type=node&node=5817259&i=0> 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>
>
>
>
>
>
>
> ------------------------------
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://postgresql.1045698.n5.nabble.com/BUG-11325-Documentation-Bug-RFE-tp5817245p5817259.html
>  To unsubscribe from BUG #11325: Documentation Bug / RFE, click here
>
<http://postgresql.1045698.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5817245&code=ZGF2aWQuZy5qb2huc3RvbkBnbWFpbC5jb218NTgxNzI0NXwtMzI2NTA0MzIx>
> .
> NAML
>
<http://postgresql.1045698.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>


queries_7-2-1-1_v1a.diff (4K) <http://postgresql.1045698.n5.nabble.com/attachment/5817262/0/queries_7-2-1-1_v1a.diff>




--
View this message in context:
http://postgresql.1045698.n5.nabble.com/BUG-11325-Documentation-Bug-RFE-tp5817245p5817262.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: harukat@sraoss.co.jp
Date:
Subject: BUG #11335: an invalid prepare statement causes crash at log_statement = 'mod' or 'ddl'.