Re: [JDBC] New driver logging proposal

Поиск
Список
Период
Сортировка
Искать
От
Vladimir Sitnikov
Тема
Re: [JDBC] New driver logging proposal
Дата
Msg-id
CAB=Je-ELgOR3zot+qWoan87Dtqno1dz1JV2cob8Z5yvZO4bxTQ@mail.gmail.com
Ответ на
Список
Дерево обсуждения
[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>
Re: New driver logging proposal Vladimir Sitnikov <sitnikov.vladimir@gmail.com>
Re: 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 Dave Cramer <pg@fastcrypt.com>
Re: New driver logging proposal Jorge Solórzano <jorsol@gmail.com>
Re: [JDBC] New driver logging proposal Dave Cramer <pg@fastcrypt.com>
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 по дате отправления
От: Philippe Marschall
Дата:
От: Jorge Solórzano
Дата:
FAQ