follow below.
Kind regards,
Julian Markwort
julian.markw...@uni-muenster.de
Things I noticed:
1.
when using either
CREATE ROLE
ALTER ROLE
with the parameter
ENCRYPTED
md5 encryption is always assumed (I've come to realize that
UNENCRYPTED always equa
looking forward to any feedback,
Julian
--
Julian Markwort
Westphalian Wilhelms-University in Münster
julian.markw...@uni-muenster.de
diff --git a/src/interfaces/libpq/fe-connect.c b/src/interfaces/libpq/fe-connect.c
index 9b2839b..5c0d88a 100644
--- a/src/interfaces/libpq/fe-connect.c
+++ b/src
I haven't really thought about this as I had been asked to make this
work as an additional option to the connection parameters...
Now that I've looked at it - there is really only the benefit of saving
the step of setting the PGPASSFILE environment variable.
However, there might be cases in which
On 09/26/2016 07:51 PM, Robert Haas wrote:
However, they don't have
to accept the possibility that arbitrary local files readable by the
user ID will be used for authentication and/or disclosed; this patch
would force them to accept that risk.
I do agree with you, however we might have to take a
age when the custom pgpassfile hasn't been
found would be helpful.
Kind regards,
Julian
--
Julian Markwort
Westphalian Wilhelms-University in Münster
julian(dot)markwort(at)uni-muenster(dot)de
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index 4e34f00..1bd5597 100644
--- a
Thanks for your quick response, Fabien
I think that PGPASSFILE is somehow checked twice
yup, that was unintended redundancy...
I would suggest that the struct gets the value (from option,
environment or default) and is always used elsewhere. The
getPgPassFilename function should disappear and
rd was necessary, we must have tried that pgpassfile, so i got rid
of the field "dot_pgpass_used" in the pg_conn struct and the pgpassfile
string is always used in the error message.
3. Going on, I renamed "dot_pg_pass_warning()" to "PGPassFileWarning()"
Kind regar
Welp, I was in head over heels, sorry for my messy email...
*2. No more "dot_pgpass_used" - we fill the conn->pgpassfile field with
any options that have been provided (connection parameter, environment
variable, "default" ~/.pgpass) and in case there has been an error with
the authentificatio
Am 01.11.2016 um 15:14 schrieb Fabien COELHO:
Thus, when returning with an error, if conn->pgpassfile was set and a
password was necessary, we must have tried that pgpassfile, so i got
rid of the field "dot_pgpass_used"
No, you should not have done that, because it changes a feature which
w
ssage on every connection string that doesn't
specify a pgpassfile or password, since .pgpass will be checked every time,
before prompting the user to input the password)
regards,
Julian Markwort
pgpassfile_v4.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-h
Any improvements would be greatly welcome by the admin
community, I'm sure.
That's good to hear - on the other hand, I really appreciate the opinion
of admins on this idea!
However, this is a rather large change which could be destabilizing to
the many users of this extension.
I'm fully aware of
Alright, for the next version of this patch I'll look into standard
deviation (an implementation of Welfords' algorithm already exists in
pg_stat_statements).
On 3/4/17 14:18, Peter Eisentraut wrote:
The other problem is that this measures execution time, which can vary
for reasons other than
Hello psql-hackers!
TL:DR;
We extended the functionality of pg_stat_statements so it can track
worst and best case execution plans.
Based on a suggestion of my colleague Arne Scheffer, Marius Timmer and I
extended pg_stat_statements so it can also record execution plans,
whenever the executi
Fabien Coelho wrote:
A few detailed comments:
Beware of spacing:
. "if(" -> "if (" (2 instances)
. " =='\0')" -> " == '\0')" (at least one instance)
Elsewhere:
+ if (conn->pgpassfile_used && conn->password_needed && conn->result &&
+ conn->pgpassfile && conn->pgpassfile[0]!='\0' &&
IS
14 matches
Mail list logo
