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
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
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
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
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
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
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
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
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
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
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
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
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
14 matches
Mail list logo
