Allow changing log level after connection is established. Because
log level and loggers can be set independently, it is now possible
to have a log level above none when there is a nil logger. This
means all log statements need to check for nil logger and an
appropriate log level. This check has been factored out into
*Conn.shouldLog.
Allow replacing logger after connection is established. Also
refactor internals of logging such that there is a log method that
adds the pid to all log calls instead of making a new logger object.
The reason for this is so pid will be logged regardless of whether
loggers are replaced and restored.
Add tests for sslmode parameter when calling ParseURI. Fix existing tests to work since default sslmode is 'prefer'
Make sure we default to prefer if sslmode is not provided in ParseDSN
Fix existing tests for ParseDSN to expect TLS configuration for prefer since prefer is the default sslmode; also, add tests for ParseDSN when specifying sslmode parameter on connection string
PostgreSQL has two string syntaxes, one that allows backslash escapes and one
that does not (SQL standard conforming strings). By default PostgreSQL uses
standard conforming strings. QuoteString was only designed for use with
standard conforming strings. If PostgreSQL was configured with certain
combinations of the standard_conforming_strings and backslash_quote settings,
QuoteString may not correctly sanitize strings. QuoteString was only used in
unprepared queries, bound parameters are used for prepared queries.
This commit alters pgx to use always use bound parameters.
As a consequence of never doing string interpolation there is no need to have
separate Text and Binary encoders. There is now only the Encoder interface.
This change had a negative effect on the performance of simple unprepared
queries, but prepared statements should already be used for performance.
fixes#26https://github.com/jackc/pgx/issues/26
Benchmarks revealed that it is no longer performant enough to pull
its own wait. Using go_db_bench to copy JSON results to HTTP responses
it was ~20% *slower* for ~4BK responses and less than 10% faster for
+1MB responses.
The the performance problem was in io.CopyN / io.Copy. io.Copy
allocates a 32KB buffer if it doesn't have io.WriterTo or io.ReaderFrom
available. This extra alloc on every request was more expensive than
just reading the result into a string and writing it out to the response
body.
Tests indicated that if MsgReader implemented a custom Copy that used a
shared buffer it might have a few percent performance advantage. But the
additional complexity is not worth the performance gain.