Update version 11 release notes.

Remove description of commit 1944cdc98, which has now been back-patched
so it's not relevant to v11 any longer.  Add descriptions of other
recent commits that seemed worth mentioning.

I marked the update as stopping at 2018-07-30, because it's unclear
whether d06eebce5 will be allowed to stay in v11, and I didn't feel like
putting effort into writing a description of it yet.  If it does stay,
I think it will deserve mention in the Source Code section.

diff --git a/doc/src/sgml/release-11.sgml b/doc/src/sgml/release-11.sgml
index 1b21794e5aa227bc6be47f226706041c1440eca3..95e6e06cd3bc0068d5f70e35e108bf7c0a66d85b 100644 (file)
--- a/doc/src/sgml/release-11.sgml
+++ b/doc/src/sgml/release-11.sgml
@@ -6,7 +6,7 @@
 
   
    Release date:
-   2018-??-?? (CURRENT AS OF 2018-05-01)
+   2018-??-?? (CURRENT AS OF 2018-07-30)
   
 
   
@@ -217,6 +217,60 @@
 
       
 
+
+       
+        Consider syntactic form when disambiguating function versus column
+        references (Tom Lane)
+       
+
+       
+        When x is a table name or composite
+        column, PostgreSQL has traditionally
+        considered the syntactic
+        forms f(x)
+        and x.f
+        to be equivalent, allowing tricks such as writing a function and
+        then using it as though it were a computed-on-demand column.
+        However, if both interpretations are feasible, the column
+        interpretation was always chosen, leading to surprising results if
+        the user intended the function interpretation.  Now, if there is
+        ambiguity, the interpretation that matches the syntactic form is
+        chosen.
+       
+      
+
+      
+
+
+       
+        Make power(numeric, numeric)
+        and power(float8, float8)
+        handle NaN inputs according to the POSIX standard
+        (Tom Lane, Dang Minh Huong)
+       
+
+       
+        POSIX says that NaN ^ 0 = 1 and 1 ^ NaN
+        = 1, but all other cases with NaN
+        input(s) should return NaN.
+        power(numeric, numeric) just
+        returned NaN in all such cases; now it honors the
+        two exceptions.  power(float8, float8) followed
+        the standard if the C library does; but on some old Unix platforms
+        the library doesn't, and there were also problems on some versions
+        of Windows.
+       
+      
+
+      
+
 
@@ -274,22 +328,19 @@
 
       
 
 
        
-        Have libpq's 
-        linkend="libpq-pqhost">PQhost()
-        always return the actual connected host (Haribabu Kommi)
+        Correctly handle relative path expressions
+        in xmltable(), xpath(),
+        and other XML-handling functions (Markus Winand)
        
 
        
-        Previously PQhost() often returned the
-        supplied host parameters, which could contain several hosts.
-        It will now also return the host's IP address if the host name was
-        not supplied.  The same is true of PQport(),
-        which now returns the actual port number, not the multiple supplied
-        port numbers.
+        Per the SQL standard, relative paths start from the document node of
+        the XML input document, not the root node as these functions
+        formerly did it.
        
       
 
@@ -425,19 +476,6 @@
        
       
 
-      
-
-
-       
-        Consistently return NaN for
-        NaN inputs to power()
-        on older platforms (Tom Lane, Dang Minh Huong)
-       
-
-      
-
    
 
   
@@ -1428,6 +1466,7 @@ same commits as above
       
 
 
        
@@ -2616,6 +2655,24 @@ same commits as above
 
       
 
+
+       
+        Use stdbool.h to define type bool
+        on platforms where it's suitable, which is most (Peter Eisentraut)
+       
+
+       
+        This eliminates a coding hazard for extension modules that need
+        to include stdbool.h.
+       
+      
+
+      
+
 
        
@@ -2732,11 +2794,12 @@ same commits as above
       
 
 
        
         Update to use perltidy version
-        20170521 (Tom Lane)
+        20170521 (Tom Lane, Peter Eisentraut)