When code was added to use a random named portal instead of the empty portal to support redshift we didn't update the close messages approprately. This could result in postgres keeping locks on tables for modification if streaming and table modification was both done within a transaction. This update fixes the issue by always issuing a close command on the named portal when query is finished.
fixes#56
There are no tests covering cursor.end(). It's also a weird method to have on the cursor as it terminates the connection to postgres internally. I don't recall why I added this method in the first place but its not correct to close a connection to postgres by calling .end on a cursor...seems like a pretty big footgun. If you have a pooled client and you call `cursor.end` it'll close the client internally and likely confuse the pool. Plus it's just weird to be able to close a connection by calling .end on a query or cursor. So...I'm deprecating that method.
Close is used to release a named portal (which isn't used by pg-cursor) or when you're early-terminating a cursor on the unnamed portal. Sending 'close' on an connection which has already sent 'readyForQuery' results in the connection responding with a _second_ 'readyForQuery' which causes a lot of issues within node-postgres as 'readyForQuery' is the signal to indicate the client has gone back into the idle state.
