Re: [JDBC] New driver logging proposal - Mailing list pgsql-jdbc

From Vladimir Sitnikov
Subject Re: [JDBC] New driver logging proposal
Date
Msg-id CAB=Je-ELgOR3zot+qWoan87Dtqno1dz1JV2cob8Z5yvZO4bxTQ@mail.gmail.com
Whole thread Raw
In response to Re: [JDBC] New driver logging proposal  (Daniel Migowski <dmigowski@ikoffice.de>)
Responses Re: [JDBC] New driver logging proposal  (Jorge Solórzano <jorsol@gmail.com>)
Re: [JDBC] New driver logging proposal  (Daniel Migowski <dmigowski@ikoffice.de>)
Re: New driver logging proposal  (Jorge Solórzano <jorsol@gmail.com>)
Re: New driver logging proposal  (Daniel Migowski <dmigowski@ikoffice.de>)
List 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

pgsql-jdbc by date:

Previous
From: Philippe Marschall
Date:
Subject: [JDBC] [pgjdbc/pgjdbc] 4ab5cc: feat: support fetching a REF_CURSOR usinggetObjec...
Next
From: Jorge Solórzano
Date:
Subject: Re: [JDBC] New driver logging proposal