Re: PG 12 draft release notes

On Mon, May 20, 2019 at 08:48:15PM -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2019-05-20 18:56:50 -0400, Tom Lane wrote:
> >> 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:
> 
> >> Author: Tom Lane <tgl@sss.pgh.pa.us>
> >> 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?
> 
> Yes, this should be in "source code".  I think it should be merged
> with a391ff3c and 74dfe58a into something like
> 
>     Allow extensions to create planner support functions that
>     can provide function-specific selectivity, cost, and
>         row-count estimates that can depend on the function arguments.
>         Support functions can also transform WHERE clauses involving
>         an extension's functions and operators into indexable clauses
>         in ways that the core code cannot for lack of detailed semantic
>     knowledge of those functions/operators.

The new text is:

        Add support function capability to improve optimizer estimates
        for functions (Tom Lane)

        This allows extensions to create planner support functions that
        can provide function-specific selectivity, cost, and row-count
        estimates that can depend on the function arguments.  Also, improve
        in-core estimates for <function>generate_series()</function>,
        <function>unnest()</function>, and functions that return boolean
        values.

Notice that there are some improvments in in-core functions. Should this
still be moved to the source code section?

> > and perhaps you could opine on whether we ought to include
> 
> >> <listitem>
> >> <!--
> >> Author: Tom Lane <tgl@sss.pgh.pa.us>
> >> 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>
> 
> It's probably worth mentioning, but I'd say something like
> 
>         Fix bugs that could cause ALTER TABLE DETACH PARTITION
>         to not drop objects that should be dropped, such as
>         automatically-created child indexes.
> 
> The rest of it is not terribly interesting from a user's standpoint,
> I think.

Done.

-- 
  Bruce Momjian  <bruce@momjian.us>        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 +