Re: New driver logging proposal

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

>

In response to

Responses

Browse pgsql-jdbc by date

  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...