Re: New driver logging proposal

Hello Vladimir,

Von: Vladimir Sitnikov [mailto:sitnikov(dot)vladimir(at)gmail(dot)com]
Gesendet: Sonntag, 9. April 2017 23:55

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"?

I didn’t want to use slfj, also because it is still another extra layer that does the logging. The layer I wanted to add would have added a NullLogger, where all logging functions have empty code, are inlined by the JVM and each call would result in assembly code that does only check if the instance of the logger is still the NullLogger and then does nothing more! It just thought this to be cleaner than log level caching, because then we can spare the level caching code. Think of the wrapper as exactly that: A log level cache.

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.

I wanted to use an incrementing ID as a connection ID, didn’t know the term meant something else.