From: | Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com> |
---|---|
To: | Daniel Migowski <dmigowski(at)ikoffice(dot)de> |
Cc: | "pgsql-jdbc(at)postgresql(dot)org" <pgsql-jdbc(at)postgresql(dot)org>, Jorge Solórzano <jorsol(at)gmail(dot)com> |
Subject: | Re: New driver logging proposal |
Date: | 2017-04-09 21:54:34 |
Message-ID: | CAB=Je-ELgOR3zot+qWoan87Dtqno1dz1JV2cob8Z5yvZO4bxTQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
Daniel,
I wonder if adding "logging=true" property is required to meed the
performance requirements at all.
I would like to refrain from adding new configuration options.
What bothers me with "replace jul with abc" approach is it will be yet
another 100500+lines change that is hard to review.
I wonder how far can we go with keeping jul interfaces. Is it
possible/enough to just add relevant "log level caching at the
resultset/etc levels"?
Daniel>Show connection IDs in the log messages to identify connections, and
not in logging categories
ConnectionIDs are unpredictable, so I can hardly imagine a case when
end-user would activate logging based on the connection id (e.g. enable
debug for a specific ID only).
On the other hand, having something like
"org.postgresql.sql.DB_NAME.USER_NAME.CONN_ID" as a logging category could
make sense.
Vladimir
>
From | Date | Subject | |
---|---|---|---|
Next Message | Jorge Solórzano | 2017-04-10 00:42:59 | Re: New driver logging proposal |
Previous Message | Philippe Marschall | 2017-04-09 20:03:05 | [pgjdbc/pgjdbc] 4ab5cc: feat: support fetching a REF_CURSOR using getObjec... |