pike.git
/
lib
/
modules
/
Sql.pmod
/
pgsql.pike
version
»
Context lines:
10
20
40
80
file
none
3
pike.git/lib/modules/Sql.pmod/pgsql.pike:1910:
else if(syncparse) portal._unnamedstatementkey=unnamedstatement->lock(1); // Even though the protocol doesn't require the Parse command to be // followed by a flush, it makes a VERY noticeable difference in // performance if it is omitted; seems like a flaw in the PostgreSQL // server v8.3.3 PD("Parse statement %O=%O\n",preparedname,q); plugbuffer=c->start()->add_int8('P') ->add_hstring(({preparedname,0,q,"\0\0\0"}),4,4)->add(PGFLUSH); }
+
portal._preparedname=preparedname;
if(!tp || !tp.datatypeoid) { PD("Describe statement %O\n",preparedname); (plugbuffer||c->start())->add_int8('D') ->add_hstring(({'S',preparedname,0}),4,4)->sendcmd(FLUSHSEND,portal); } else { if(plugbuffer) plugbuffer->sendcmd(KEEP); #ifdef PG_STATS skippeddescribe++; #endif portal->_setrowdesc(tp.datarowdesc); }
-
portal._preparedname=preparedname;
+
if((portal._tprepared=tp) && tp.datatypeoid) { mixed e=catch(portal->_preparebind(tp.datatypeoid)); if(e && !portal._delayederror) throw(e); } } throwdelayederror(portal); return portal; }