On 04/26/2017 07:57 PM, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Wed, Apr 26, 2017 at 6:22 AM, Heikki Linnakangas <hlinnaka@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
avoid it.
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
> avoid that.
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.
- Heikki
