Re: PG 14 release notes, first draft - Mailing list pgsql-hackers

On Tue, May 11, 2021 at 05:13:21PM -0500, Justin Pryzby wrote:
> On Tue, May 11, 2021 at 10:35:23AM -0400, Bruce Momjian wrote:
> > > | Allow more than the common name (CN) to be matched for client certificate authentication (Andrew Dunstan) 
> > > Your description makes it sound like arbitrary attributes can be compared.  But
> > > the option just allows comparing CN or DN.
> > 
> > OK, new text is:
> > 
> >     <para>
> >     Allow the certificate's distinguished name (DN) to be matched for client
> >     certificate authentication (Andrew Dunstan)
> >     </para>
> >     
> >     <para>
> >     The new pg_hba.conf keyword "clientname=DN" allows comparison with
> >     non-CN certificate attributes and can be combined with ident maps.
> >     </para>
> >     </listitem>
> 
> I think this part is still misleading.  The option just allows DN/CN, so it's
> strange to say "non-CN attributes".

OK, so this is where I am confused.  I searched for distinguished name
(DN) and came up with DN being a concatentation of all the fields
provided to the certificate signing request (CSR).  Is that right? 
Wouldn't people test _parts_ of the DN, rather than all of it.  The test
in the patch seems to do that:

+     "# MAPNAME       SYSTEM-USERNAME                           PG-USERNAME\n",
+     "dn             \"CN=ssltestuser-dn,OU=Testing,OU=Engineering,O=PGDG\"    ssltestuser\n",
+     "dnre           \"/^.*OU=Testing,.*\$\"                    ssltestuser\n",
+     "cn              ssltestuser-dn                            ssltestuser\n";

I think someone need to explain to me exactly what the DN is and how it
is used.  Sorry.

> > > | Add date_bin function (John Naylor) 
> > > This truncate timestamps on an arbitrary interval.
> > > Like date_trunc() but also supports eg. '15 minutes', and also uses an arbitrary "origin".
> > 
> > OK, so what I think it returns is the greatest datetime that is a
> > multiple of interval values added to origin which is not greater than
> > the target date, right?  Am I the only one who finds this unclear? 
> > Doesn't our documentation of this feature need to explain this?
> 
> I think the documentation is okay, myself:
> https://www.postgresql.org/docs/devel/functions-datetime.html#FUNCTIONS-DATETIME-BIN
> | The function date_bin “bins” the input timestamp into the specified interval (the stride)...

OK, if everyone else is happy with it, I am fine.  I now have:

    <listitem>
    <!--
    Author: Peter Eisentraut <peter@eisentraut.org>
    2021-03-24 [49ab61f0b] Add date_bin function
    Author: Peter Eisentraut <peter@eisentraut.org>
    2021-04-10 [496e58bb0] Improve behavior of date_bin with origin in the
    future
    -->
    
    <para>
    Add date_bin function (John Naylor)
    </para>
    
    <para>
    The function date_bin "bins" the input timestamp into a specified
    interval aligned with a specified origin.
    </para>
    </listitem>

> Anyway, the release notes have to be at least as succiently as that.
> 
> +Allow VACUUM to eagerly add newly deleted btree pages in the free space map (Peter Geoghegan)
> 
> say added "to" the FSM

Yes, fixed.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  If only the physical world exists, free will is an illusion.