Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> * Add GSSAPI encryption support (Robbie Harwood, Stephen Frost)
> This allows TCP/IP connections to be encrypted when using GSSAPI
> authentication without having to set up a separate encryption facility
> like SSL.
Hmm, does that imply that you don't have to have compiled --with-openssl,
or just that you don't have to bother with setting up SSL certificates?
But you already don't have to do the latter. I'd be the first to admit
that I know nothing about GSSAPI, but this text still doesn't enlighten
me about why I should learn.
>> * Discovery of LDAP servers if PostgreSQL is built with OpenLDAP
> I would remove the "if" part from the major features list, since it's a
> qualification of minor importance.
OK
>> * Allow data type name to use non-C collations
> I'm not sure why that is listed in the "Migration" section.
I think Bruce was reacting to this comment in the commit log for
478cacb50:
Prior to v12, if you used a collation-sensitive regex feature in a
pattern handled by processSQLNamePattern() (for instance, \d '\\w+'
in psql), the behavior you got matched the database's default collation.
Since commit 586b98fdf you'd usually get C-collation behavior, because
the catalog "name"-type columns are now marked as COLLATE "C". Add
explicit COLLATE specifications to restore the prior behavior.
(Note for whoever writes the v12 release notes: the need for this shows
that while 586b98fdf preserved pre-v12 behavior of "name" columns for
simple comparison operators, it changed the behavior of regex operators
on those columns. Although this patch fixes it for pattern matches
generated by our own tools, user-written queries will still be affected.
So we'd better mention this issue as a compatibility item.)
The existing text for this item doesn't make that aspect clear
enough, perhaps.
regards, tom lane