v3 notes updated

v3.md

@@ -20,12 +20,18 @@ Conn.Pid changed to accessor method Conn.PID()
 
 Remove Conn.TxStatus
 
+Added Context methods
+
+Conn.WaitForNotification now takes context.Context instead of time.Duration for cancellation support.
+
+Conn.WaitForNotification no longer automatically pings internally every 15 seconds. (Reconsider this later...)
+
+ReplicationConn.WaitForReplicationMessage now takes context.Context instead of time.Duration for cancellation support.
+
 ## TODO / Possible / Investigate
 
 Organize errors better
 
-Optionally use Go 1.7 context / cancel and timeouts could be implemented this way
-
 Remove circular dependency between Conn and ConnPool such that ConnPool depends on Conn, but Conn doesn't know anything about ConnPool
 
 Extract types Null* and Hstore to separate package
@@ -34,6 +40,8 @@ Remove names from prepared statements - use database/sql style objects
 
 Better way of handling text/binary protocol choice than pgx.DefaultTypeFormats or manually editing a PreparedStatement. Possibly an optional part of preparing a statement is specifying the format and/or a decoder. Or maybe it is part of a QueryEx call... Could be very interesting to make encoding and decoding possible without being a method of the type. This could drastically clean up those huge type switches.
 
+Also maybe support binary and text for everything possible
+
 Copy protocol support (this potentially ties in with text/binary protocol)
 ValueReader / msgReader cleanup
 
@@ -44,3 +52,8 @@ Every field that should not be set by user should be replaced by accessor method
 Investigate strongly typed queries. i.e. Some sort of interface where varargs of Query, Exec, and Scan wouldn't happen. Need to be some low-level interface where (probably generated) functions could (more or less) directly read and write to the connection.
 
 Reject scanning non-string like things into a string (e.g. binary encoded timestamptz to string). See https://github.com/jackc/pgx/issues/223
+
+Further clean up logging interface -- still some pre-loglevel code in place
+Possibly integrate internal logging support with context. Possibly add method that adds arbitrary pgx log data to context. Or add ability to configure what key(s) pgx looks at for additional log context.
+Consider whether to switch to logrus style or stick with log15 style logs
+Keep ability to change logging while running