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?
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.
Would it be worth making password_encryption be GUC_REPORT so that
it could be guaranteed available, without a server transaction,
from any valid connection? I'm generally resistant to adding
GUC_REPORT flags, but maybe this is a time for an exception.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
