From 87790fd1eaa5d2cd50c15ac55bfbcda602dfd272 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Sat, 4 Aug 2018 23:49:53 -0400 Subject: [PATCH] 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. --- doc/src/sgml/release-11.sgml | 113 +++++++++++++++++++++++++++-------- 1 file changed, 88 insertions(+), 25 deletions(-) diff --git a/doc/src/sgml/release-11.sgml b/doc/src/sgml/release-11.sgml index 1b21794e5a..95e6e06cd3 100644 --- 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 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)