On Nov 10, 2013 2:45 PM, "Maciek Sakrejda" <notifications@github.com> wrote:
>
> In conn.go:
>
> > @@ -438,6 +470,9 @@ func (cn *conn) prepareToSimpleStmt(q, stmtName
string) (_ *stmt, err error) {
> >  }
> >
> >  func (cn *conn) Prepare(q string) (driver.Stmt, error) {
> > + if len(q) >= 4 && strings.EqualFold(q[:4], "COPY") {
>>
>> IIRC the problem is that one needs to know not to do a real 'prepare'
(which doesn't work with utility statements like COPY) for COPY statements,
which is why such sniffing is tempting: one must use the 'simple' query
protocol instead, if memory serves.
>
> Ah, I see. Never mind on that part, then.

COPY ought to support vacuous prepare semantics. :-(

>> So instead of db.Prepare => Stmt as in this patch, how about db.Exec =>
Result? Result is an interface. If the user knows a-priori it is a COPY (as
they probably do...) then it can be type-asserted into a Copy
implementation.
>
> Given that there is no contract that guarantees those types are handed to
users without any intermediate delegating wrappers, this is playing with
fire. This is how people got into trouble with JDBC all the time when
trying to cast to concrete types in the presence of things like pooling.

Do you mean like pgbouncer, or do you mean pooling integrated with the
application like database/sql?