Re: SCRAM in the PG 10 release notes

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Noah Misch <noah(at)leadboat(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Andreas Karlsson <andreas(at)proxel(dot)se>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SCRAM in the PG 10 release notes
Date: 2017-09-20 14:06:26
Message-ID: CA+Tgmob6MeQ5cTcYrCbeUhmeiDiHgugiOCTALWPKu6SiyS4MBA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Sep 20, 2017 at 9:42 AM, Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
> I don't have any expectation that that list will be kept up to date.

Ditto. I suggest removing this as an open item. There's no defect in
the code alleged, and whether there is a defect in the documentation
is a matter of opinion on which not everyone agrees. The open items
list is not a club to force committers to change things in a way that
the person adding it likes better; it is a means for ensuring that
clear defects get addressed in a timely manner so that we can have a
timely release.

In my opinion, it would be useful and appropriate to document
migration instructions. However, I think the burden of doing that in
an appropriate way is on whoever wants it done, not on Heikki, just
like any other change that somebody wants made. Also in my opinion,
it would be inappropriate to encourage people to migrate to SCRAM.
Our job is to provide features, not to admonish users that they must
use them. We could equally well add notes to the documentation
saying:

* Installations using out-of-core logical replication are encouraged
to consider whether our built-in logical replication is now a better
option.

* Installations using table inheritance for partitioning should
consider using the new table partitioning feature instead.

* Installations using btree indexes on wide keys with equality
comparisons only should consider whether hash indexes are now a better
alternative.

But let's not. Let's just do what we're already doing - tell people
what we've got and let them decide whether to use it.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2017-09-20 14:09:38 Re: Allow GiST opcalsses without compress\decompres functions
Previous Message Tom Lane 2017-09-20 14:02:35 Re: Allow GiST opcalsses without compress\decompres functions