On 04/26/2017 07:57 PM, Tom Lane wrote:
Robert Haas <robertmh...@gmail.com> writes:
On Wed, Apr 26, 2017 at 6:22 AM, Heikki Linnakangas <hlinn...@iki.fi> wrote:
* If algorithm is not given explicitly, PQencryptPasswordConn() queries
"SHOW password_encryption", and uses that. That is documented, and it is
also documented that it will *not* issue queries, and hence will not block,
if the algorithm is given explicitly. That's an important property for some
applications. If you want the default behavior without blocking, query "SHOW
password_encryption" yourself, and pass the result as the 'algorithm'.
TBH, I'd just require the user to specify the algorithm explicitly.
Having it run SHOW on the server seems wonky. It introduces a bunch
of failure modes for ... no real benefit, I think.
Yeah. Blocking is the least of your worries --- what about being in
a failed transaction, for instance?
Well, the "ALTER USER" command that you will surely run next, using the
same connection, would fail anyway. I don't think running a query is a
problem, as long as it's documented, and there's a documented way to
You could argue, that since we need to document how to avoid the query
and the blocking, we might as well always require the application to run
the "show password_encryption" query before calling
PQencryptPasswordConn(). But I'd like to offer the convenience for the
majority of applications that don't mind blocking.
However, it's not entirely true that there's no real benefit. If the
client app has to specify the algorithm then client code will need
extension every time we add another algorithm. Maybe that's going to
happen so seldom that it's not a big deal, but it would be nice to
Yeah, I'd like to be prepared. Hopefully we don't need to add another
algorithm any time soon, but maybe we will, or maybe we want to add an
option for the SCRAM iteration count, for example.
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: