When debugging, it is important to easily understand the queries we are dealing with. When needed, getting at their parameters should also be relatively easy.
Similarly, custom loggers should be able to get such basic information without too much hassle.

Currently, it is quite hard to get that information from pgjdbc because it involves a lot of reflection, breaks at every upgrade of the library, and getting certain fields is definitely not easy.

Thus, I suggest the following:

• PgPreparedStatement should be public so we can easily cast a PreparedStatement.
• The default toString() of PgPreparedStatement and PgCallableStatement should be the raw SQL statement that was used to construct the statement (meaning with '?' for bind parameters).
• Before any addBatch(), possibility to get all parameters. This should be done with methods like getParameterCount(), getSqlParameterTypes(), getPgParameterTypes(), getParameterValues() (using null or "?" if not bound, Sql Parameter Type allowing to differentiate).

A bit of background: all our stack goes through methods for statements to execute, add batch, execute batch. We can activate logging and get a lot of information (stacktrace of every call, time to execute, etc.) and with Postgres we are blind: it is not easy to get basic information about the statements. Moreover, when we debug in our IDE we get similar issues.