Docs postgresql 9.4 merge ga (#7208)

* REASSIGN OWNED. edits. Remove qualification that it doesn't change the database ownership

* ALTER FUNCTION. set from current clause description revision

* COMMENT. capitalize proper noun.

* COPY. describe PROGRAM option.

* CREATE AGGREGATE. Implements new syntax.

* CREATE FUNCTION. edits.

* DROP ROLE. small edit, link to other commands

* DROP USER. trivial edit.

* PREPARE. small edits

* REASSIGN OWNED. Trivial edits.

* REINDEX. trivial edit.

* pg_dump. use --quote-all-identifers for cross-version dumps

* Additional edits

* Updates from review

* Updates from review

gpdb-doc/dita/ref_guide/sql_commands/ALTER_FUNCTION.xml

@@ -139,7 +139,8 @@ RESET ALL</codeblock></section>
               <codeph>RESET</codeph> is used, the function-local setting is removed, and the
             function executes with the value present in its environment. Use <codeph>RESET
               ALL</codeph> to clear all function-local settings. <codeph>SET FROM CURRENT</codeph>
-            applies the session's current value of the parameter when the function is entered.</pd>
+            saves the value of the parameter that is current when <codeph>ALTER FUNCTION</codeph> is
+            executed as the value to be applied when the function is entered.</pd>
         </plentry>
         <plentry>
           <pt>RESTRICT</pt>

gpdb-doc/dita/ref_guide/sql_commands/ALTER_TABLE.xml

@@ -1023,8 +1023,7 @@ where <varname>action</varname> is one of:
                         <codeblock>ALTER TABLE distributors ADD CONSTRAINT zipchk CHECK 
 (char_length(zipcode) = 5);</codeblock>
                         <p>To add a check constraint only to a table and not to its children:</p>
-                        <codeblock>ALTER TABLE distributors ADD CONSTRAINT zipchk CHECK (char_length(zipcode) = 5) NO INHERIT 
-;</codeblock>
+                        <codeblock>ALTER TABLE distributors ADD CONSTRAINT zipchk CHECK (char_length(zipcode) = 5) NO INHERIT;</codeblock>
                         <p>(The check constraint will not be inherited by future children, either.)</p>
 
                         <p>Remove a check constraint from a table and all of its children:</p>

gpdb-doc/dita/ref_guide/sql_commands/COMMENT.xml

@@ -177,7 +177,7 @@ COMMENT ON SERVER myserver IS 'my foreign server';
 COMMENT ON TABLE my_schema.my_table IS 'Employee Information';
 COMMENT ON TABLESPACE my_tablespace IS 'Tablespace for indexes';
 COMMENT ON TEXT SEARCH CONFIGURATION my_config IS 'Special word filtering';
-COMMENT ON TEXT SEARCH DICTIONARY swedish IS 'Snowball stemmer for swedish language';
+COMMENT ON TEXT SEARCH DICTIONARY swedish IS 'Snowball stemmer for Swedish language';
 COMMENT ON TEXT SEARCH PARSER my_parser IS 'Splits text into words';
 COMMENT ON TEXT SEARCH TEMPLATE snowball IS 'Snowball stemmer';
 COMMENT ON TRIGGER my_trigger ON my_table IS 'Used for RI';

gpdb-doc/dita/ref_guide/sql_commands/COPY.xml

@@ -66,6 +66,10 @@ IGNORE EXTERNAL PARTITIONS</codeblock></p>
         as <codeph>gpfdist</codeph>, which is useful for high speed data loading. </p>
       <note type="warning"> Use of the <codeph>ON SEGMENT</codeph> clause is recommended for expert
         users only.</note>
+      <p>When <codeph>PROGRAM</codeph> is specified, the server executes the given command and reads
+        from the standard output of the program, or writes to the standard input of the program. The
+        command must be specified from the viewpoint of the server, and be executable by the <codeph>gpadmin</codeph>
+        user.</p>
       <p>When <codeph>STDIN</codeph> or <codeph>STDOUT</codeph> is specified, data is transmitted
         via the connection between the client and the master. <codeph>STDIN</codeph> and
           <codeph>STDOUT</codeph> cannot be used with the <codeph>ON SEGMENT</codeph> clause.</p>

gpdb-doc/dita/ref_guide/sql_commands/CREATE_FUNCTION.xml

@@ -290,8 +290,9 @@ SELECT foo();</codeblock><p>In
                     <pd>The <codeph>SET</codeph> clause applies a value to a session configuration
                         parameter when the function is entered. The configuration parameter is
                         restored to its prior value when the function exits. <codeph>SET FROM
-                            CURRENT</codeph> applies the session's current value of the parameter
-                        when the function is entered.</pd>
+                            CURRENT</codeph> saves the value of the parameter that is current when
+                            <codeph>CREATE FUNCTION</codeph> is executed as the value to be applied
+                        when the function is entered. </pd>
                 </plentry>
                 <plentry>
                     <pt><varname>definition</varname></pt>
@@ -308,7 +309,11 @@ SELECT foo();</codeblock><p>In
                         dynamically loadable object, and <varname>link_symbol</varname> is the name
                         of the function in the C language source code. If the link symbol is
                         omitted, it is assumed to be the same as the name of the SQL function being
-                        defined. It is recommended to locate shared libraries either relative to
+                        defined. The C names
+                        of all functions must be different, so you must give overloaded SQL
+                        functions different C names (for example, use the argument types as
+                        part of the C names).
+                        It is recommended to locate shared libraries either relative to
                             <codeph>$libdir</codeph> (which is located at
                             <codeph>$GPHOME/lib</codeph>) or through the dynamic library path (set
                         by the <codeph>dynamic_library_path</codeph> server configuration

gpdb-doc/dita/ref_guide/sql_commands/DROP_ROLE.xml

@@ -3,12 +3,12 @@
   PUBLIC "-//OASIS//DTD DITA Composite//EN" "ditabase.dtd">
 <topic id="topic1"><title id="dd20941">DROP ROLE</title><body><p id="sql_command_desc">Removes a database role.</p><section id="section2"><title>Synopsis</title><codeblock id="sql_command_synopsis">DROP ROLE [IF EXISTS] <varname>name</varname> [, ...]</codeblock></section><section id="section3"><title>Description</title><p><codeph>DROP ROLE</codeph> removes the specified role(s). To drop a
 superuser role, you must be a superuser yourself. To drop non-superuser
-roles, you must have <codeph>CREATEROLE</codeph> privilege.</p><p>A role cannot be removed if it is still referenced in any database;
-an error will be raised if so. Before dropping the role, you must drop
-all the objects it owns (or reassign their ownership) and revoke any
-privileges the role has been granted. The <codeph>REASSIGN OWNED</codeph>
-and <codeph>DROP OWNED</codeph> commands can be useful for this purpose.
-</p><p>However, it is not necessary to remove role memberships involving
+roles, you must have <codeph>CREATEROLE</codeph> privilege.</p><p>A role cannot be removed if it is still referenced in any database; an error will be raised if
+        so. Before dropping the role, you must drop all the objects it owns (or reassign their
+        ownership) and revoke any privileges the role has been granted on other objects. The
+            <codeph><xref href="REASSIGN_OWNED.xml#topic1">REASSIGN OWNED</xref></codeph> and
+            <codeph><xref href="DROP_OWNED.xml#topic1">DROP OWNED</xref></codeph> commands can be
+        useful for this purpose. </p><p>However, it is not necessary to remove role memberships involving
 the role; <codeph>DROP ROLE</codeph> automatically revokes any memberships
 of the target role in other roles, and of other roles in the target role.
 The other roles are not dropped nor otherwise affected.</p></section><section id="section4"><title>Parameters</title><parml><plentry><pt>IF EXISTS</pt><pd>Do not throw an error if the role does not exist. A notice is issued

gpdb-doc/dita/ref_guide/sql_commands/PREPARE.xml

@@ -10,14 +10,13 @@
   issued, the prepared statement is planned and executed. This division
   of labor avoids repetitive parse analysis work, while allowing
   the execution plan to depend on the specific parameter values supplied.</p>
-  <p>Prepared statements can take parameters: values that are substituted
-into the statement when it is executed. When creating the prepared statement,
-refer to parameters by position, using <codeph>$1</codeph>, <codeph>$2</codeph>,
-etc. A corresponding list of parameter data types can optionally be specified.
-When a parameter's data type is not specified or is declared as unknown,
-the type is inferred from the context in which the parameter is used
-(if possible). When executing the statement, specify the actual values
-for these parameters in the <codeph>EXECUTE</codeph> statement.</p><p>Prepared statements only last for the duration of the current database session. When the session
+  <p>Prepared statements can take parameters: values that are substituted into the statement when it
+        is executed. When creating the prepared statement, refer to parameters by position, using
+          <codeph>$1</codeph>, <codeph>$2</codeph>, etc. A corresponding list of parameter data
+        types can optionally be specified. When a parameter's data type is not specified or is
+        declared as unknown, the type is inferred from the context in which the parameter is first
+        used (if possible). When executing the statement, specify the actual values for these
+        parameters in the <codeph>EXECUTE</codeph> statement.</p><p>Prepared statements only last for the duration of the current database session. When the session
         ends, the prepared statement is forgotten, so it must be recreated before being used again.
         This also means that a single prepared statement cannot be used by multiple simultaneous
         database clients; however, each client can create their own prepared statement to use. 
@@ -31,11 +30,10 @@ the statement is relatively simple to plan and rewrite but relatively
 expensive to execute, the performance advantage of prepared statements
 will be less noticeable.</p></section><section id="section4"><title>Parameters</title><parml><plentry><pt><varname>name</varname></pt><pd>An arbitrary name given to this particular prepared statement. It
 must be unique within a single session and is subsequently used to execute
-or deallocate a previously prepared statement.</pd></plentry><plentry><pt><varname>datatype</varname></pt><pd>The data type of a parameter to the prepared statement. If the data
-type of a particular parameter is unspecified or is specified as unknown,
-it will be inferred from the context in which the parameter is used.
-To refer to the parameters in the prepared statement itself, use <codeph>$1</codeph>,
-<codeph>$2</codeph>, etc. </pd></plentry><plentry><pt><varname>statement</varname></pt><pd>Any <codeph>SELECT</codeph>, <codeph>INSERT</codeph>, <codeph>UPDATE</codeph>,
+or deallocate a previously prepared statement.</pd></plentry><plentry><pt><varname>datatype</varname></pt><pd>The data type of a parameter to the prepared statement. If the data type of a particular
+            parameter is unspecified or is specified as unknown, it will be inferred from the
+            context in which the parameter is first used. To refer to the parameters in the prepared
+            statement itself, use <codeph>$1</codeph>, <codeph>$2</codeph>, etc. </pd></plentry><plentry><pt><varname>statement</varname></pt><pd>Any <codeph>SELECT</codeph>, <codeph>INSERT</codeph>, <codeph>UPDATE</codeph>,
 <codeph>DELETE</codeph>, or <codeph>VALUES</codeph> statement.</pd></plentry></parml></section><section id="section5"><title>Notes</title>
       <p>If a prepared statement is executed enough times, the server may eventually decide to save
         and re-use a generic plan rather than re-planning each time. This will occur immediately if

gpdb-doc/dita/ref_guide/sql_commands/REASSIGN_OWNED.xml

@@ -12,6 +12,7 @@
     <section id="section3">
       <title>Description</title>
       <p><codeph>REASSIGN OWNED</codeph> changes the ownership of database objects owned by any of
+
         the <varname>old_role</varname>s to <varname>new_role</varname>. </p>
     </section>
     <section id="section4">
@@ -38,10 +39,10 @@
       <p><codeph>REASSIGN OWNED</codeph> requires privileges on both the
         source role(s) and the target role.</p>
       <p>The <xref href="DROP_OWNED.xml#topic1"><codeph>DROP OWNED</codeph></xref> command is an
-        alternative that drops all the database objects owned by one or more roles. <codeph>DROP
-          OWNED</codeph> requires privileges only on the source role(s).</p>
-      <p>The <codeph>REASSIGN OWNED</codeph> command does not affect the privileges granted to the
-        old roles in objects that are not owned by them. Use <codeph>DROP OWNED</codeph> to revoke
+        alternative that simply drops all of the database objects owned by one or more roles.
+          <codeph>DROP OWNED</codeph> requires privileges only on the source role(s).</p>
+      <p>The <codeph>REASSIGN OWNED</codeph> command does not affect any privileges granted to the
+        old roles for objects that are not owned by them. Use <codeph>DROP OWNED</codeph> to revoke
         those privileges.</p>
     </section>
     <section id="section6">
@@ -52,7 +53,7 @@
     </section>
     <section id="section7">
       <title>Compatibility</title>
-      <p>The <codeph>REASSIGN OWNED</codeph> statement is a Greenplum Database extension. </p>
+      <p>The <codeph>REASSIGN OWNED</codeph> command is a Greenplum Database extension. </p>
     </section>
     <section id="section8">
       <title>See Also</title>

gpdb-doc/dita/ref_guide/sql_commands/REINDEX.xml

@@ -55,7 +55,7 @@
           <codeph>REINDEX</codeph> locks out writes but not reads of the index's parent table. It
         also takes an exclusive lock on the specific index being processed, which will block reads
         that attempt to use that index. In contrast, <codeph>DROP INDEX</codeph> momentarily takes
-        exclusive lock on the parent table, blocking both writes and reads. The subsequent
+        an exclusive lock on the parent table, blocking both writes and reads. The subsequent
           <codeph>CREATE INDEX</codeph> locks out writes but not reads; since the index is not
         there, no read will attempt to use it, meaning that there will be no blocking but reads may
         be forced into expensive sequential scans. </p>

gpdb-doc/dita/utility_guide/client_utilities/pg_dump.xml

@@ -83,8 +83,12 @@
             <pt>-b | --blobs</pt>
             <pd>Include large objects in the dump. This is the default behavior except when
                 <codeph>--schema</codeph>, <codeph>--table</codeph>, or
-                <codeph>--schema-only</codeph> is specified, so the <codeph>-b</codeph> switch is
-              only useful to add large objects to selective dumps.<note>Greenplum Database does not
+                <codeph>--schema-only</codeph> is specified. The <codeph>-b</codeph> switch is
+              only useful add large objects to dumps
+              where a specific schema or table has been requested. Note that
+              blobs are considered data and therefore will be included when
+              <codeph>--data-only</codeph> is used, but not when <codeph>--schema-only</codeph> is.
+              <note>Greenplum Database does not
                 support the PostgreSQL <xref
                   href="https://www.postgresql.org/docs/9.4/largeobjects.html" format="html"
                   scope="external">large object facility</xref> for streaming user data that is
@@ -153,7 +157,7 @@
                   href="./pg_restore.xml#topic1" type="topic" format="dita"/></codeph>. The tar
               format is compatible with the directory format; extracting a tar-format archive
               produces a valid directory-format archive. However, the tar format does not support
-              compression and has a limit of 8 GB on the size of individual tables. Also, the
+              compression. Also, when using tar format the
               relative order of table data items cannot be changed during restore.</pd>
           </plentry>
           <plentry>
@@ -375,6 +379,12 @@
             <pd> To exclude data for all tables in the database, see <codeph>--schema-only</codeph>.
             </pd>
           </plentry>
+          <plentry>
+            <pt><codeph>--if-exists</codeph></pt>
+            <pd> Use conditional commands (i.e. add an <codeph>IF EXISTS</codeph> clause) when
+              cleaning database objects. This option is not valid unless <codeph>--clean</codeph> is
+              also specified. </pd>
+          </plentry>         
           <plentry>
             <pt>--inserts</pt>
             <pd>Dump data as <codeph>INSERT</codeph> commands (rather than <codeph>COPY</codeph>).
@@ -563,17 +573,26 @@
           <codeph>pg_dump</codeph> emits commands to disable triggers on user tables before
         inserting the data and commands to re-enable them after the data has been inserted. If the
         restore is stopped in the middle, the system catalogs may be left in the wrong state.</p>
-      <p>Members of <codeph>tar</codeph> archives are limited to a size less than 8 GB. (This is an
-        inherent limitation of the <codeph>tar</codeph> file format.) Therefore this format cannot
-        be used if the textual representation of any one table exceeds that size. The total size of
-        a tar archive and any of the other output formats is not limited, except possibly by the
-        operating system.</p>
       <p>The dump file produced by <codeph>pg_dump</codeph> does not contain the statistics used by
         the optimizer to make query planning decisions. Therefore, it is wise to run
-          <codeph>ANALYZE</codeph> after restoring from a dump file to ensure optimal performance.</p>
+          <codeph>ANALYZE</codeph> after restoring from a dump file to ensure optimal
+        performance.</p>
       <p>The database activity of <codeph>pg_dump</codeph> is normally collected by the statistics
         collector. If this is undesirable, you can set parameter <codeph>track_counts</codeph> to
         false via <codeph>PGOPTIONS</codeph> or the <codeph>ALTER USER</codeph> command.</p>
+      <p>Because <codeph>pg_dump</codeph> may be used to transfer data to newer versions of
+        Greenplum Database, the output of <codeph>pg_dump</codeph> can be expected to load into
+        Greenplum Database versions newer than <codeph>pg_dump</codeph>'s version.
+          <codeph>pg_dump</codeph> can also dump from Greenplum Database versions older than its own
+        version. However, <codeph>pg_dump</codeph> cannot dump from Greenplum Database versions
+        newer than its own major version; it will refuse to even try, rather than risk making an
+        invalid dump. Also, it is not guaranteed that <codeph>pg_dump</codeph>'s output can be
+        loaded into a server of an older major version — not even if the dump was taken from a
+        server of that version. Loading a dump file into an older server may require manual editing
+        of the dump file to remove syntax not understood by the older server. Use of the
+          <codeph>--quote-all-identifiers</codeph> option is recommended in cross-version cases, as
+        it can prevent problems arising from varying reserved-word lists in different Greenplum
+        Database versions.</p>
     </section>
     <section id="section8">
       <title>Examples</title>