From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: PG 14 release notes, first draft |
Date: | 2021-05-12 02:45:04 |
Message-ID: | 20210512024504.GH6088@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)eisentraut(dot)org>
2021-03-24 [49ab61f0b] Add date_bin function
Author: Peter Eisentraut <peter(at)eisentraut(dot)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(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com
If only the physical world exists, free will is an illusion.
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2021-05-12 03:37:50 | Re: Replication slot stats misgivings |
Previous Message | Julien Rouhaud | 2021-05-12 02:42:01 | Re: compute_query_id and pg_stat_statements |