On 2019-05-20 18:56:50 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> 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 <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? And
> isn't the most important part of this set of changes
>
> commit 74dfe58a5927b22c744b29534e67bfdd203ac028
> Author: Tom Lane <tgl@sss.pgh.pa.us>
> 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 <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>
>
> 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