PG 12 draft release notes

classic Classic list List threaded Threaded
60 messages Options
123
Reply | Threaded
Open this post in threaded view
|

PG 12 draft release notes

Bruce Momjian
I have posted a draft copy of the PG 12 release notes here:

        http://momjian.us/pgsql_docs/release-12.html

They are committed to git.  It includes links to the main docs, where
appropriate.  Our official developer docs will rebuild in a few hours.

--
  Bruce Momjian  <[hidden email]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +


Reply | Threaded
Open this post in threaded view
|

Re: PG 12 draft release notes

Oleg Bartunov-3
Bruce,

I noticed that jsonpath in your version is mentioned only in functions
chapter, but  commit
72b6460336e86ad5cafd3426af6013c7d8457367 is about implementation of
SQL-2016 standard. We implemented JSON Path language as a jsonpath
datatype with a bunch of support functions, our implementation
supports 14 out of 15 features and it's the most complete
implementation (we compared oracle, mysql and ms sql).

On Sat, May 11, 2019 at 11:33 PM Bruce Momjian <[hidden email]> wrote:

>
> I have posted a draft copy of the PG 12 release notes here:
>
>         http://momjian.us/pgsql_docs/release-12.html
>
> They are committed to git.  It includes links to the main docs, where
> appropriate.  Our official developer docs will rebuild in a few hours.
>
> --
>   Bruce Momjian  <[hidden email]>        http://momjian.us
>   EnterpriseDB                             http://enterprisedb.com
>
> + As you are, so once was I.  As I am, so you will be. +
> +                      Ancient Roman grave inscription +
>
>


--
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company


Reply | Threaded
Open this post in threaded view
|

Re: PG 12 draft release notes

Bruce Momjian
On Sun, May 12, 2019 at 10:00:38AM +0300, Oleg Bartunov wrote:
> Bruce,
>
> I noticed that jsonpath in your version is mentioned only in functions
> chapter, but  commit
> 72b6460336e86ad5cafd3426af6013c7d8457367 is about implementation of
> SQL-2016 standard. We implemented JSON Path language as a jsonpath
> datatype with a bunch of support functions, our implementation
> supports 14 out of 15 features and it's the most complete
> implementation (we compared oracle, mysql and ms sql).

Glad you asked.  I was very confused about why a data type was added for
a new path syntax.  Is it a new storage format for JSON, or something
else?  I need help on this.

--
  Bruce Momjian  <[hidden email]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +


Reply | Threaded
Open this post in threaded view
|

Re: PG 12 draft release notes

Jonathan S. Katz-3
In reply to this post by Bruce Momjian
Hi Bruce,

On 5/11/19 4:33 PM, Bruce Momjian wrote:
> I have posted a draft copy of the PG 12 release notes here:
>
> http://momjian.us/pgsql_docs/release-12.html
>
> They are committed to git.  It includes links to the main docs, where
> appropriate.  Our official developer docs will rebuild in a few hours.

Thank you for working on this, I know it's a gargantuan task.

I have a small modification for a section entitled "Source Code" which
is a repeat of the previous section. Based on the bullet points in that
part, I thought "Documentation" might be a more appropriate name; please
see attached.

Thanks,

Jonathan

release.patch (550 bytes) Download Attachment
signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: PG 12 draft release notes

David Rowley-3
In reply to this post by Bruce Momjian
On Sun, 12 May 2019 at 08:33, Bruce Momjian <[hidden email]> wrote:
>
> I have posted a draft copy of the PG 12 release notes here:
>
>         http://momjian.us/pgsql_docs/release-12.html

I noticed a couple of different spellings of Álvaro's name.  Loading
the file line by line into a table and crudely performing:

select distinct name from (select
trim(regexp_split_to_table(substring(a, '\((.*?)\)'),',')) as name
from r where a like '%(%)%')a order by name;

turned up variations in Michaël and Pavel's names

The attached fixes.

--
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

normalise_release_note_names.patch (11K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: PG 12 draft release notes

Bruce Momjian
In reply to this post by Jonathan S. Katz-3
On Sun, May 12, 2019 at 10:49:07AM -0400, Jonathan Katz wrote:

> Hi Bruce,
>
> On 5/11/19 4:33 PM, Bruce Momjian wrote:
> > I have posted a draft copy of the PG 12 release notes here:
> >
> > http://momjian.us/pgsql_docs/release-12.html
> >
> > They are committed to git.  It includes links to the main docs, where
> > appropriate.  Our official developer docs will rebuild in a few hours.
>
> Thank you for working on this, I know it's a gargantuan task.
>
> I have a small modification for a section entitled "Source Code" which
> is a repeat of the previous section. Based on the bullet points in that
> part, I thought "Documentation" might be a more appropriate name; please
> see attached.

Yes, I saw that myself and just updated it.  Thanks.

---------------------------------------------------------------------------


>
> Thanks,
>
> Jonathan

> diff --git a/doc/src/sgml/release-12.sgml b/doc/src/sgml/release-12.sgml
> index 5f5d1da33d..1bbd91a02e 100644
> --- a/doc/src/sgml/release-12.sgml
> +++ b/doc/src/sgml/release-12.sgml
> @@ -2617,7 +2617,7 @@ Require a C99-supported compiler, and <acronym>MSCV</acronym> 2013 or later on <
>     </sect3>
>  
>     <sect3>
> -    <title>Source Code</title>
> +    <title>Documentation</title>
>  
>       <itemizedlist>
>  





--
  Bruce Momjian  <[hidden email]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +


Reply | Threaded
Open this post in threaded view
|

Re: PG 12 draft release notes

Bruce Momjian
In reply to this post by Bruce Momjian
On Sun, May 12, 2019 at 09:49:40AM -0400, Bruce Momjian wrote:

> On Sun, May 12, 2019 at 10:00:38AM +0300, Oleg Bartunov wrote:
> > Bruce,
> >
> > I noticed that jsonpath in your version is mentioned only in functions
> > chapter, but  commit
> > 72b6460336e86ad5cafd3426af6013c7d8457367 is about implementation of
> > SQL-2016 standard. We implemented JSON Path language as a jsonpath
> > datatype with a bunch of support functions, our implementation
> > supports 14 out of 15 features and it's the most complete
> > implementation (we compared oracle, mysql and ms sql).
>
> Glad you asked.  I was very confused about why a data type was added for
> a new path syntax.  Is it a new storage format for JSON, or something
> else?  I need help on this.

I talked to Alexander Korotkov on chat about this.  The data types are
used as arguments to the functions, similar to how tsquery and tsvector
are used for full text search.

Therefore, the data types are not really useful on their own, but as
support for path functions.  However, path functions are more like JSON
queries, rather than traditional functions, so it odd to list them under
functions, but there isn't a more reasonable place to put them.

Alexander researched how we listed full text search in the release notes
that added the feature, but we had  "General" category at that time that
we don't have now.

--
  Bruce Momjian  <[hidden email]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +


Reply | Threaded
Open this post in threaded view
|

Re: PG 12 draft release notes

Bruce Momjian
In reply to this post by David Rowley-3
On Mon, May 13, 2019 at 01:37:25PM +1200, David Rowley wrote:

> On Sun, 12 May 2019 at 08:33, Bruce Momjian <[hidden email]> wrote:
> >
> > I have posted a draft copy of the PG 12 release notes here:
> >
> >         http://momjian.us/pgsql_docs/release-12.html
>
> I noticed a couple of different spellings of Álvaro's name.  Loading
> the file line by line into a table and crudely performing:
>
> select distinct name from (select
> trim(regexp_split_to_table(substring(a, '\((.*?)\)'),',')) as name
> from r where a like '%(%)%')a order by name;
>
> turned up variations in Michaël and Pavel's names

That is a big help, thanks, applied.

--
  Bruce Momjian  <[hidden email]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +


Reply | Threaded
Open this post in threaded view
|

Re: PG 12 draft release notes

Fabien COELHO-3
In reply to this post by Bruce Momjian

Hello Bruce,

> I have posted a draft copy of the PG 12 release notes here:
>
> http://momjian.us/pgsql_docs/release-12.html
>
> They are committed to git.  It includes links to the main docs, where
> appropriate.  Our official developer docs will rebuild in a few hours.

Pgbench entry "Improve pgbench error reporting with clearer messages and
return codes" is by Peter Eisentraut, not me. I just reviewed it.

--
Fabien.


Reply | Threaded
Open this post in threaded view
|

Re: PG 12 draft release notes

Oleg Bartunov-3
In reply to this post by Bruce Momjian
On Mon, May 13, 2019 at 6:52 AM Bruce Momjian <[hidden email]> wrote:

>
> On Sun, May 12, 2019 at 09:49:40AM -0400, Bruce Momjian wrote:
> > On Sun, May 12, 2019 at 10:00:38AM +0300, Oleg Bartunov wrote:
> > > Bruce,
> > >
> > > I noticed that jsonpath in your version is mentioned only in functions
> > > chapter, but  commit
> > > 72b6460336e86ad5cafd3426af6013c7d8457367 is about implementation of
> > > SQL-2016 standard. We implemented JSON Path language as a jsonpath
> > > datatype with a bunch of support functions, our implementation
> > > supports 14 out of 15 features and it's the most complete
> > > implementation (we compared oracle, mysql and ms sql).
> >
> > Glad you asked.  I was very confused about why a data type was added for
> > a new path syntax.  Is it a new storage format for JSON, or something
> > else?  I need help on this.
>
> I talked to Alexander Korotkov on chat about this.  The data types are
> used as arguments to the functions, similar to how tsquery and tsvector
> are used for full text search.
>
> Therefore, the data types are not really useful on their own, but as
> support for path functions.  However, path functions are more like JSON
> queries, rather than traditional functions, so it odd to list them under
> functions, but there isn't a more reasonable place to put them.
>
> Alexander researched how we listed full text search in the release notes
> that added the feature, but we had  "General" category at that time that
> we don't have now.
I attached slide about our Jsonpath implementation in Postgres, it
summarizes the reasons to have jsonpath data type. But my point was:
JSON Path is a part of SQL-2016 standard and I think it's worth to
mention it, not just a set of jsonb functions.

>
> --
>   Bruce Momjian  <[hidden email]>        http://momjian.us
>   EnterpriseDB                             http://enterprisedb.com
>
> + As you are, so once was I.  As I am, so you will be. +
> +                      Ancient Roman grave inscription +



--
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

Screenshot 2019-05-13 at 10.04.21.png (76K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: PG 12 draft release notes

Bruce Momjian
In reply to this post by Fabien COELHO-3
On Mon, May 13, 2019 at 08:41:25AM +0200, Fabien COELHO wrote:

>
> Hello Bruce,
>
> > I have posted a draft copy of the PG 12 release notes here:
> >
> > http://momjian.us/pgsql_docs/release-12.html
> >
> > They are committed to git.  It includes links to the main docs, where
> > appropriate.  Our official developer docs will rebuild in a few hours.
>
> Pgbench entry "Improve pgbench error reporting with clearer messages and
> return codes" is by Peter Eisentraut, not me. I just reviewed it.

Thanks, fixed.

--
  Bruce Momjian  <[hidden email]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +


Reply | Threaded
Open this post in threaded view
|

Re: PG 12 draft release notes

Bruce Momjian
In reply to this post by Oleg Bartunov-3
On Mon, May 13, 2019 at 10:08:57AM +0300, Oleg Bartunov wrote:

> On Mon, May 13, 2019 at 6:52 AM Bruce Momjian <[hidden email]> wrote:
> >
> > On Sun, May 12, 2019 at 09:49:40AM -0400, Bruce Momjian wrote:
> > > On Sun, May 12, 2019 at 10:00:38AM +0300, Oleg Bartunov wrote:
> > > > Bruce,
> > > >
> > > > I noticed that jsonpath in your version is mentioned only in functions
> > > > chapter, but  commit
> > > > 72b6460336e86ad5cafd3426af6013c7d8457367 is about implementation of
> > > > SQL-2016 standard. We implemented JSON Path language as a jsonpath
> > > > datatype with a bunch of support functions, our implementation
> > > > supports 14 out of 15 features and it's the most complete
> > > > implementation (we compared oracle, mysql and ms sql).
> > >
> > > Glad you asked.  I was very confused about why a data type was added for
> > > a new path syntax.  Is it a new storage format for JSON, or something
> > > else?  I need help on this.
> >
> > I talked to Alexander Korotkov on chat about this.  The data types are
> > used as arguments to the functions, similar to how tsquery and tsvector
> > are used for full text search.
> >
> > Therefore, the data types are not really useful on their own, but as
> > support for path functions.  However, path functions are more like JSON
> > queries, rather than traditional functions, so it odd to list them under
> > functions, but there isn't a more reasonable place to put them.
> >
> > Alexander researched how we listed full text search in the release notes
> > that added the feature, but we had  "General" category at that time that
> > we don't have now.
>
> I attached slide about our Jsonpath implementation in Postgres, it
> summarizes the reasons to have jsonpath data type. But my point was:
> JSON Path is a part of SQL-2016 standard and I think it's worth to
> mention it, not just a set of jsonb functions.

So, are you suggesting we mention the jsonpath data type in the Data
Type section, even though it is useless without jsonpath, which is in
another section, or are you suggesting to move the jsonpath item to the
Data Type section?

--
  Bruce Momjian  <[hidden email]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +


Reply | Threaded
Open this post in threaded view
|

Re: PG 12 draft release notes

nickb
In reply to this post by Bruce Momjian
On Sat, May 11, 2019, at 22:33, Bruce Momjian wrote:
> http://momjian.us/pgsql_docs/release-12.html

There is a typo in E.1.3.1.1.:
> Expressions are evaluated at table partitioned table creation time.
First "table" seems to be excessive.

Regards,
Nick.


Reply | Threaded
Open this post in threaded view
|

Re: PG 12 draft release notes

Bruce Momjian
On Tue, May 14, 2019 at 11:53:23AM +0200, nickb wrote:
> On Sat, May 11, 2019, at 22:33, Bruce Momjian wrote:
> > http://momjian.us/pgsql_docs/release-12.html
>
> There is a typo in E.1.3.1.1.:
> > Expressions are evaluated at table partitioned table creation time.
> First "table" seems to be excessive.

Yep, fixed, thanks.

--
  Bruce Momjian  <[hidden email]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +


Reply | Threaded
Open this post in threaded view
|

Re: PG 12 draft release notes

Andres Freund
In reply to this post by Bruce Momjian
Hi,

Note that I've added a few questions to individuals involved with
specific points. If you're in the To: list, please search for your name.


On 2019-05-11 16:33:24 -0400, Bruce Momjian wrote:
> I have posted a draft copy of the PG 12 release notes here:
>
> http://momjian.us/pgsql_docs/release-12.html
> They are committed to git.

Thanks!

  <title>Migration to Version 12</title>

There's a number of features in the compat section that are more general
improvements with a side of incompatibility. Won't it be confusing to
e.g. have have the ryu floating point conversion speedups in the compat
section, but not in the "General Performance" section?


     <para>
      Remove the special behavior of <link
      linkend="datatype-oid">OID</link> columns (Andres Freund,
      John Naylor)
     </para>

Should we mention that tables with OIDs have to have their oids removed
before they can be upgraded?


     <para>
      Refactor <link linkend="functions-geometry">geometric
      functions</link> and operators (Emre Hasegeli)
     </para>

     <para>
      This could lead to more accurate, but slightly different, results
      from previous releases.
     </para>
    </listitem>
    <listitem>
<!--
Author: Tomas Vondra <[hidden email]>
2018-08-16 [c4c340088] Use the built-in float datatypes to implement geometric
-->

     <para>
      Restructure <link linkend="datatype-geometric">geometric
      types</link> to handle NaN, underflow, overflow and division by
      zero more consistently (Emre Hasegeli)
     </para>
    </listitem>

    <listitem>
<!--
Author: Tomas Vondra <[hidden email]>
2018-09-26 [2e2a392de] Fix problems in handling the line data type
-->

     <para>
      Improve behavior and error reporting for the <link
      linkend="datatype-geometric">line data type</link> (Emre Hasegeli)
     </para>
    </listitem>

Is that sufficient explanation? Feels like we need to expand a bit
more. In particular, is it possible that a subset of the changes here
require reindexing?

Also, aren't three different entries a bit too much?


     <para>
      Avoid performing unnecessary rounding of <link
      linkend="datatype-float"><type>REAL</type></link> and <type>DOUBLE
      PRECISION</type> values (Andrew Gierth)
     </para>

     <para>
      This dramatically speeds up processing of floating-point
      values but causes additional trailing digits to
      potentially be displayed.  Users wishing to have output
      that is rounded to match the previous behavior can set <link
      linkend="guc-extra-float-digits"><literal>extra_float_digits=0</literal></link>,
      which is no longer the default.
     </para>
    </listitem>

Isn't it exactly the *other* way round? *Previously* we'd output
additional trailing digits. The new algorithm instead will instead have
*exactly* the required number of digits?


      <listitem>
<!--
Author: Tom Lane <[hidden email]>
2019-02-11 [1d92a0c9f] Redesign the partition dependency mechanism.
-->

       <para>
        Improve handling of partition dependency (Tom Lane)
       </para>

       <para>
        This prevents the creation of inconsistent partition hierarchies
        in rare cases.
       </para>
      </listitem>

That seems not very informative for users?


      <listitem>
<!--
Author: Alexander Korotkov <[hidden email]>
2018-07-28 [d2086b08b] Reduce path length for locking leaf B-tree pages during
Author: Peter Geoghegan <[hidden email]>
2019-03-25 [f21668f32] Add "split after new tuple" nbtree optimization.
-->

       <para>
        Improve speed of btree index insertions (Peter Geoghegan,
        Alexander Korotkov)
       </para>

       <para>
        The new code improves the space-efficiency of page splits,
        reduces locking overhead, and gives better performance for
        <command>UPDATE</command>s and <command>DELETE</command>s on
        indexes with many duplicates.
       </para>
      </listitem>

      <listitem>
<!--
Author: Peter Geoghegan <[hidden email]>
2019-03-20 [dd299df81] Make heap TID a tiebreaker nbtree index column.
Author: Peter Geoghegan <[hidden email]>
2019-03-20 [fab250243] Consider secondary factors during nbtree splits.
-->

       <para>
        Have new btree indexes sort duplicate index entries in heap-storage
        order (Peter Geoghegan, Heikki Linnakangas)
       </para>

       <para>
        Indexes <application>pg_upgraded</application> from previous
        releases will not have this ordering.
       </para>
      </listitem>

I'm not sure that the grouping here is quite right. And the second entry
probably should have some explanation about the benefits?


      <listitem>
<!--
Author: Peter Eisentraut <[hidden email]>
2018-11-14 [1b5d797cd] Lower lock level for renaming indexes
-->

       <para>
        Reduce locking requirements for index renaming (Peter Eisentraut)
       </para>
      </listitem>

Should we specify the newly required lock level? Because it's quire
relevant for users what exactly they're now able to do concurrently in
operation?


       <para>
        Allow <link linkend="queries-with">common table expressions</link>
        (<acronym>CTE</acronym>) to be inlined in later parts of the query
        (Andreas Karlsson, Andrew Gierth, David Fetter, Tom Lane)
       </para>

       <para>
        Specifically, <acronym>CTE</acronym>s are inlined
        if they are not recursive and are referenced only
        once later in the query.  Inlining can be prevented by
        specifying <literal>MATERIALIZED</literal>, and forced by
        specifying <literal>NOT MATERIALIZED</literal>.  Previously,
        <acronym>CTE</acronym>s were never inlined and were always
        evaluated before the rest of the query.
       </para>

Hm. Is it actually correct to say that "were always evaluated before the
rest of the query."? My understanding is that that's not actually how
they behaved. Materialization for CTE scans was on-demand (i.e. when
needed by a CTE scan), and even for DML CTEs we'd only force the
underlying query to completion at the end of the query?



      <listitem>
<!--
Author: Tom Lane <[hidden email]>
2019-02-09 [1fb57af92] Create the infrastructure for planner support functions.
-->

       <para>
        Add support for <link linkend="sql-createfunction">function
        selectivity</link> (Tom Lane)
       </para>
      </listitem>

Hm, that message doesn't seem like an accurate description of that
commit (if anything it's a391ff3c?). Given that it all requires C
hackery, perhaps we ought to move it to the source code section? And
isn't the most important part of this set of changes

commit 74dfe58a5927b22c744b29534e67bfdd203ac028
Author: Tom Lane <[hidden email]>
Date:   2019-02-11 21:26:08 -0500

    Allow extensions to generate lossy index conditions.


      <listitem>
<!--
Author: Tomas Vondra <[hidden email]>
2019-01-29 [36a1281f8] Separate per-batch and per-tuple memory contexts in COPY
Author: Heikki Linnakangas <[hidden email]>
2019-01-25 [9556aa01c] Use single-byte Boyer-Moore-Horspool search even with mu
Author: Andres Freund <[hidden email]>
2019-01-26 [a9c35cf85] Change function call information to be variable length.
-->

       <para>
        Greatly reduce memory consumption of <xref linkend="sql-copy"/>
        and function calls (Andres Freund, Tomas Vondra, Tom Lane)
       </para>
      </listitem>

Grouping these three changes together makes no sense to me.

I think the first commit just ought not to be mentioned separately, it's
just a fix for a memory leak in 31f3817402, essentially a 12 only bugfix?

The second commit is about position() etc, which seems not to match that
description either?

The third is probably more appropriate to be in the source code
section. While it does speed up function calls a bit (in particular
plpgsql which is very function call heavy), it also is a breaking change
for some external code? Not sure why Tom is listed with this entry?


      <listitem>
<!--
Author: Heikki Linnakangas <[hidden email]>
2019-01-25 [9556aa01c] Use single-byte Boyer-Moore-Horspool search even with mu
-->

       <para>
        Improve search performance for multi-byte characters (Heikki
        Linnakangas)
       </para>
      </listitem>

That's the second reference to the commit. I suspect this is much better
separate, so I'd just remove it from above.


      <listitem>
<!--
Author: Stephen Frost <[hidden email]>
2019-04-02 [4d0e994ee] Add support for partial TOAST decompression
-->

       <para>
        Allow <link linkend="storage-toast"><literal>TOAST</literal></link>
        values to be minimally decompressed (Paul Ramsey)
       </para>

I'd s/minimal/partial/ - I don't think the code guarantees anything
about it being minimal? And "minimally decompressed" also is somewhat
confusing, because it sounds like it's about the compression quality
rather than only decompressing part of the data.


      <listitem>
<!--
Author: Michael Paquier <[hidden email]>
2018-08-10 [f841ceb26] Improve TRUNCATE by avoiding early lock queue
-->

       <para>
        Prevent <xref linkend="sql-truncate"/> from requesting a lock on
        tables for which it lacks permission (Michaël Paquier)
       </para>

       <para>
        This prevents unauthorized locking delays.
       </para>
      </listitem>

      <listitem>
<!--
Author: Michael Paquier <[hidden email]>
2018-08-27 [a556549d7] Improve VACUUM and ANALYZE by avoiding early lock queue
-->

       <para>
        Prevent <command>VACUUM</command> and <command>ANALYZE</command>
        from requesting a lock on tables for which it lacks permission
        (Michaël Paquier)
       </para>

       <para>
        This prevents unauthorized locking delays.
       </para>
      </listitem>


I don't think this should be in the <title><acronym>Authentication</acronym></title>
section.

Also perhaps, s/it/the user/, or "the caller"?


      <listitem>
<!--
Author: Tom Lane <[hidden email]>
2019-03-10 [cbccac371] Reduce the default value of autovacuum_vacuum_cost_delay
-->

       <para>
        Reduce the default value of <xref
        linkend="guc-autovacuum-vacuum-cost-delay"/> to 2ms (Tom Lane)
       </para>
      </listitem>

I think this needs to explain that this can increase autovacuum's IO
throughput considerably.

      <listitem>
<!--
Author: Tom Lane <[hidden email]>
2019-03-10 [caf626b2c] Convert [autovacuum_]vacuum_cost_delay into floating-poi
-->

       <para>
        Allow <xref linkend="guc-vacuum-cost-delay"/> to specify
        sub-millisecond delays (Tom Lane)
       </para>

       <para>
        Floating-point values can also now be specified.
       </para>
      </listitem>

And this should be merged with the previous entry?


      <listitem>
<!--
Author: Tom Lane <[hidden email]>
2019-03-10 [caf626b2c] Convert [autovacuum_]vacuum_cost_delay into floating-poi
-->

       <para>
        Allow time-based server variables to use <link
        linkend="config-setting">micro-seconds</link> (us) (Tom Lane)
       </para>
      </listitem>

      <listitem>
<!--
Author: Tom Lane <[hidden email]>
2019-03-11 [1a83a80a2] Allow fractional input values for integer GUCs, and impr
-->

       <para>
        Allow fractional input for integer server variables (Tom Lane)
       </para>

       <para>
        For example, <command>SET work_mem = '30.1GB'</command>.
       </para>
      </listitem>

      <listitem>
<!--
Author: Tom Lane <[hidden email]>
2019-03-10 [caf626b2c] Convert [autovacuum_]vacuum_cost_delay into floating-poi
-->

       <para>
        Allow units to be specified for floating-point server variables
        (Tom Lane)
       </para>
      </listitem>

Can't we combine these? Seems excessively detailed in comparison to the
rest of the entries.


     <listitem>
<!--
Author: Peter Eisentraut <[hidden email]>
2019-01-11 [ff8530605] Add value 'current' for recovery_target_timeline
-->

      <para>
       Add an explicit value of <literal>current</literal> for <xref
       linkend="guc-recovery-target-time"/> (Peter Eisentraut)
      </para>
     </listitem>

Seems like this should be combined with the earlier "Cause recovery to
advance to the latest timeline by default" entry.


     <listitem>
<!--
Author: Peter Eisentraut <[hidden email]>
2019-03-30 [fc22b6623] Generated columns
-->

      <para>
       Add support for <link linkend="sql-createtable">generated
       columns</link> (Peter Eisentraut)
      </para>

      <para>
       Rather than storing a value only at row creation time, generated
       columns are also modified during updates, and can reference other
       table columns.
      </para>
     </listitem>

I find this description confusing. How about cribbing from the commit?
Roughly like

    This allows creating columns that are computed from expressions,
    including references to other columns in the same table, rather than
    having to be specified by the inserter/updater.

Think we also ought to mention that this is only stored generated
columns, given that the SQL feature also includes virtual columns?


     <listitem>
<!--
Author: Fujii Masao <[hidden email]>
2019-04-08 [119dcfad9] Add vacuum_truncate reloption.
Author: Fujii Masao <[hidden email]>
2019-05-08 [b84dbc8eb] Add TRUNCATE parameter to VACUUM.
-->

      <para>
       Add <xref linkend="sql-vacuum"/> and <command>CREATE
       TABLE</command> options to prevent <command>VACUUM</command>
       from truncating trailing empty pages (Tsunakawa Takayuki)
      </para>

      <para>
       The options are <varname>vacuum_truncate</varname> and
       <varname>toast.vacuum_truncate</varname>.  This reduces vacuum
       locking requirements.
      </para>
     </listitem>

Maybe add something like: "This can be helpful to avoid query
cancellations on standby that are not avoided by hot_standby_feedback."?


     <listitem>
<!--
Author: Robert Haas <[hidden email]>
2019-04-04 [a96c41fee] Allow VACUUM to be run with index cleanup disabled.
-->

      <para>
       Allow vacuum to avoid index cleanup with the
       <literal>INDEX_CLEANUP</literal> option (Masahiko Sawada)
      </para>
     </listitem>

I think we ought to expand a bit more on why one would do that,
including perhaps some caveat?


     <listitem>
<!--
Author: Peter Eisentraut <[hidden email]>
2019-03-19 [590a87025] Ignore attempts to add TOAST table to shared or catalog
-->

      <para>
       Allow modifications of system tables using <xref
       linkend="sql-altertable"/> (Peter Eisentraut)
      </para>

      <para>
       This allows modifications of <literal>reloptions</literal> and
       autovacuum settings.
      </para>
     </listitem>

I think the first paragraph is a bit dangerous. This does *not*
generally allow modifications of system tables using ALTER TABLE.


     <listitem>
<!--
Author: Tom Lane <[hidden email]>
2019-01-30 [5f5c01459] Allow RECORD and RECORD[] to be specified in function co
-->

      <para>
       Allow <type>RECORD</type> and <type>RECORD[]</type> to be specified
       as a function <link linkend="sql-createfunction">return-value
       record</link> (Elvis Pranskevichus)
      </para>

      <para>
       DETAIL?
      </para>
     </listitem>

This description doesn't sound accurate to me. Tom?


      <listitem>
<!--
Author: Tom Lane <[hidden email]>
2018-09-25 [5b7e03670] Avoid unnecessary precision loss for pgbench's - -rate ta
-->

       <para>
        Compute behavior based on pgbench's <option>--rate</option>
        value more precisely (Tom Lane)
       </para>
      </listitem>

"Computing behavior" sounds a bit odd. Maybe "Improve precision of
pgbench's <option>--rate</option>" option?


      <listitem>
<!--
Author: Thomas Munro <[hidden email]>
2018-07-13 [387a5cfb9] Add pg_dump - -on-conflict-do-nothing option.
-->

       <para>
        Allow restoration of an <command>INSERT</command>-statement dump
        to skip rows which would cause conflicts (Surafel Temesgen)
       </para>

       <para>
        The <application>pg_dump</application> option is
        <option>--on-conflict-do-nothing</option>.
       </para>
      </listitem>

Hm, this doesn't seem that clear. It's not really a restoration time
option, and it sounds a bit like that in the above. How about instead saying something
like:
Allow pg_dump to emit INSERT ... ON CONFLICT DO NOTHING (Surafel).


      <listitem>
<!--
Author: Andrew Dunstan <[hidden email]>
2019-02-18 [af25bc03e] Provide an extra-float-digits setting for pg_dump / pg_d
-->

       <para>
        Allow the number of float digits to be specified
        for <application>pg_dump</application> and
        <application>pg_dumpall</application> (Andrew Dunstan)
       </para>

       <para>
        This allows the float digit output to match previous dumps.
       </para>

Hm, feels like that should be combined with the ryu compat entry?


      <para>
       Add <xref linkend="sql-create-access-method"/> command to create
       new table types (Haribabu Kommi, Andres Freund, Álvaro Herrera,
       Dimitri Dolgov)
      </para>

A few points:

1) Is this really source code, given that CREATE ACCESS METHOD TYPE
   TABLE is a DDL command, and USING (...) for CREATE TABLE etc is an
   option to DDL commands?

2) I think the description sounds a bit too much like it's about new
   forms of tables, rather than their storage. How about something
   roughly like:

   Allow different <link linkend="tableam">table access methods</> to be
   <link linkend="sql-create-access-method>created</> and <link
   linkend="sql-createtable-method">used</>. This allows to develop and
   use new ways of storing and accessing table data, optimized for
   different use-cases, without having to modify
   PostgreSQL. The existing <literal>heap</literal> access method
   remains the default.

3) This misses a large set of commits around making tableam possible, in
   particular the commits around

commit 4da597edf1bae0cf0453b5ed6fc4347b6334dfe1
Author: Andres Freund <[hidden email]>
Date:   2018-11-16 16:35:11 -0800

    Make TupleTableSlots extensible, finish split of existing slot type.

   Given that those commits entail an API break relevant for extensions,
   should we have them as a separate "source code" note?

4) I think the attribution isn't quite right. For one, a few names with
   substantial work are missing (Amit Khandekar, Ashutosh Bapat,
   Alexander Korotkov), and the order doesn't quite seem right. On the
   latter part I might be somewhat petty, but I spend *many* months of
   my life on this.

   How about:
   Andres Freund, Haribabu Kommi, Alvaro Herrera, Alexander Korotkov, David Rowley, Dimitri Golgov
   if we keep 3) separate and
   Andres Freund, Haribabu Kommi, Alvaro Herrera, Ashutosh Bapat, Alexander Korotkov, Amit Khandekar, David Rowley, Dimitri Golgov
   otherwise?

   I think it might actually make sense to take David off this list,
   because his tableam work is essentially part of it's own entry, as
<!--
Author: Peter Eisentraut <[hidden email]>
2018-08-01 [0d5f05cde] Allow multi-inserts during COPY into a partitioned table
-->

       <para>
        Improve speed of <command>COPY</command> into partitioned tables
        (David Rowley)
       </para>

   since his copy.c portions of 86b85044e823a largely are a rewrite of
   the above commit.


     <listitem>
<!--
Author: Greg Stark <[hidden email]>
2018-10-09 [36e9d413a] Add "B" suffix for bytes to docs
-->

      <para>
       Document that the <literal>B</literal>/bytes units can be specified
       for <link linkend="config-setting">server variables</link>
       (Greg Stark)
      </para>
     </listitem>

Given how large changes we skip over in the release notes, I don't
really see a point in including changes like this. Feels like we'd at
the very least also have to include larger changes with typo/grammar
fixes etc?

Greetings,

Andres Freund


Reply | Threaded
Open this post in threaded view
|

Re: PG 12 draft release notes

Andrew Gierth
[ To: header pruned ]

>>>>> "Andres" == Andres Freund <[hidden email]> writes:

 Andres>      <para>
 Andres>       Avoid performing unnecessary rounding of <link
 Andres>       linkend="datatype-float"><type>REAL</type></link> and <type>DOUBLE
 Andres>       PRECISION</type> values (Andrew Gierth)
 Andres>      </para>

 Andres>      <para>
 Andres>       This dramatically speeds up processing of floating-point
 Andres>       values but causes additional trailing digits to
 Andres>       potentially be displayed.  Users wishing to have output
 Andres>       that is rounded to match the previous behavior can set <link
 Andres>       linkend="guc-extra-float-digits"><literal>extra_float_digits=0</literal></link>,
 Andres>       which is no longer the default.
 Andres>      </para>
 Andres>     </listitem>

 Andres> Isn't it exactly the *other* way round? *Previously* we'd
 Andres> output additional trailing digits. The new algorithm instead
 Andres> will instead have *exactly* the required number of digits?

Yeah, this wording is not right. But your description is also wrong.

Previously we output values rounded to 6+d or 15+d digits where
d=extra_float_digits, with d=0 being the default. Only clients that
wanted exact results would set that to 3 instead.

Now we output the minimum digits to get an exact result, which is
usually 8 or 17 digits (sometimes less depending on the value, or 9 for
the relatively rare float4 values that need it) for any
extra_float_digits value > 0. Clients that set d=3 will therefore
usually get one less digit than before, and the value they get will
usually be slightly different (i.e. not the same value that they would
have seen with d=2), but it should give them the same binary value after
going through strtod() or strtof().

--
Andrew (irc:RhodiumToad)


Reply | Threaded
Open this post in threaded view
|

Re: PG 12 draft release notes

Tom Lane-2
In reply to this post by Andres Freund
Andres Freund <[hidden email]> writes:
> Note that I've added a few questions to individuals involved with
> specific points. If you're in the To: list, please search for your name.

I'm not sure which of my commits you want me to opine on, other than

>      <listitem>
> <!--
> Author: Tom Lane <[hidden email]>
> 2019-01-30 [5f5c01459] Allow RECORD and RECORD[] to be specified in function co
> -->
>       <para>
>        Allow <type>RECORD</type> and <type>RECORD[]</type> to be specified
>        as a function <link linkend="sql-createfunction">return-value
>        record</link> (Elvis Pranskevichus)
>       </para>
>       <para>
>        DETAIL?
>       </para>
>      </listitem>

> This description doesn't sound accurate to me. Tom?

Yeah, maybe better

       Allow <type>RECORD</type> and <type>RECORD[]</type> to be used
       as column types in a query's column definition list for a
       table function that is declared to return <type>RECORD</type>
       (Elvis Pranskevichus)

You could link to "queries-tablefunctions" which describes the column
definition business; it's much more specific than "sql-createfunction".

                        regards, tom lane


Reply | Threaded
Open this post in threaded view
|

Re: PG 12 draft release notes

Andres Freund
In reply to this post by Andrew Gierth
Hi,

On 2019-05-20 23:56:33 +0100, Andrew Gierth wrote:

> [ To: header pruned ]
>
> >>>>> "Andres" == Andres Freund <[hidden email]> writes:
>
>  Andres>      <para>
>  Andres>       Avoid performing unnecessary rounding of <link
>  Andres>       linkend="datatype-float"><type>REAL</type></link> and <type>DOUBLE
>  Andres>       PRECISION</type> values (Andrew Gierth)
>  Andres>      </para>
>
>  Andres>      <para>
>  Andres>       This dramatically speeds up processing of floating-point
>  Andres>       values but causes additional trailing digits to
>  Andres>       potentially be displayed.  Users wishing to have output
>  Andres>       that is rounded to match the previous behavior can set <link
>  Andres>       linkend="guc-extra-float-digits"><literal>extra_float_digits=0</literal></link>,
>  Andres>       which is no longer the default.
>  Andres>      </para>
>  Andres>     </listitem>
>
>  Andres> Isn't it exactly the *other* way round? *Previously* we'd
>  Andres> output additional trailing digits. The new algorithm instead
>  Andres> will instead have *exactly* the required number of digits?
>
> Yeah, this wording is not right. But your description is also wrong.
>
> Previously we output values rounded to 6+d or 15+d digits where
> d=extra_float_digits, with d=0 being the default. Only clients that
> wanted exact results would set that to 3 instead.
>
> Now we output the minimum digits to get an exact result, which is
> usually 8 or 17 digits (sometimes less depending on the value, or 9 for
> the relatively rare float4 values that need it) for any
> extra_float_digits value > 0. Clients that set d=3 will therefore
> usually get one less digit than before, and the value they get will
> usually be slightly different (i.e. not the same value that they would
> have seen with d=2), but it should give them the same binary value after
> going through strtod() or strtof().

Any chance for you to propose a text?

Greetings,

Andres Freund


Reply | Threaded
Open this post in threaded view
|

Re: PG 12 draft release notes

Andrew Gierth
>>>>> "Andres" == Andres Freund <[hidden email]> writes:

 Andres> Any chance for you to propose a text?

This is what I posted before; I'm not 100% happy with it but it's still
better than any of the other versions:

 * Output REAL and DOUBLE PRECISION values in shortest-exact format by
   default, and change the behavior of extra_float_digits

   Previously, float values were output rounded to 6 or 15 decimals by
   default, with the number of decimals adjusted by extra_float_digits.
   The previous rounding behavior is no longer the default, and is now
   done only if extra_float_digits is set to zero or less; if the value
   is greater than zero (which it is by default), a shortest-precise
   representation is output (for a substantial performance improvement).
   This representation preserves the exact binary value when correctly
   read back in, even though the trailing digits will usually differ
   from the output generated by previous versions when
   extra_float_digits=3.

--
Andrew (irc:RhodiumToad)


Reply | Threaded
Open this post in threaded view
|

Re: PG 12 draft release notes

Andres Freund
In reply to this post by Tom Lane-2
On 2019-05-20 18:56:50 -0400, Tom Lane wrote:
> Andres Freund <[hidden email]> writes:
> > Note that I've added a few questions to individuals involved with
> > specific points. If you're in the To: list, please search for your name.
>
> I'm not sure which of my commits you want me to opine on, other than

That was one of the main ones. I'm also specifically wondering about:

>       <listitem>
> <!--
> Author: Tom Lane <[hidden email]>
> 2019-02-09 [1fb57af92] Create the infrastructure for planner support functions.
> -->
>
>        <para>
>         Add support for <link linkend="sql-createfunction">function
>         selectivity</link> (Tom Lane)
>        </para>
>       </listitem>
>
> Hm, that message doesn't seem like an accurate description of that
> commit (if anything it's a391ff3c?). Given that it all requires C
> hackery, perhaps we ought to move it to the source code section? And
> isn't the most important part of this set of changes
>
> commit 74dfe58a5927b22c744b29534e67bfdd203ac028
> Author: Tom Lane <[hidden email]>
> Date:   2019-02-11 21:26:08 -0500
>
>     Allow extensions to generate lossy index conditions.


and perhaps you could opine on whether we ought to include

>       <listitem>
> <!--
> Author: Tom Lane <[hidden email]>
> 2019-02-11 [1d92a0c9f] Redesign the partition dependency mechanism.
> -->
>
>        <para>
>         Improve handling of partition dependency (Tom Lane)
>        </para>
>
>        <para>
>         This prevents the creation of inconsistent partition hierarchies
>         in rare cases.
>        </para>
>       </listitem>
>
> That seems not very informative for users?

and if so provide a better description? Because no user is going to make
sense of that.

And lastly, opine on the int GUC fractions, microsoecond, and cost_delay
items?


> Yeah, maybe better
>
>        Allow <type>RECORD</type> and <type>RECORD[]</type> to be used
>        as column types in a query's column definition list for a
>        table function that is declared to return <type>RECORD</type>
>        (Elvis Pranskevichus)
>
> You could link to "queries-tablefunctions" which describes the column
> definition business; it's much more specific than "sql-createfunction".

Yea, that's much better.

Greetings,

Andres Freund


123