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:1916:
paramValues=({}); if(String.width(q)>8) ERROR("Wide string literals in %O not supported\n",q); if(has_value(q,"\0")) ERROR("Querystring %O contains invalid literal nul-characters\n",q); mapping(string:mixed) tp; int tstart; /* * FIXME What happens with regards to this detection when presented with * multistatement text-queries?
+
* The primary function of this detection is to ensure a SYNC
+
* right after a COMMIT, and no SYNC after a BEGIN.
*/ int transtype = .pgsql_util.transendprefix->match(q) ? TRANSEND : .pgsql_util.transbeginprefix->match(q) ? TRANSBEGIN : NOTRANS; if (transtype != NOTRANS) tp = .pgsql_util.describenodata; // Description already known else if (!forcetext && forcecache == 1 || forcecache && sizeof(q) >= MINPREPARELENGTH) { object plugbuffer; while(catch(plugbuffer=c->start())) reconnect();
pike.git/lib/modules/Sql.pmod/pgsql.pike:2009:
Inside #if 0
->add_hstring(({preparedname,0,q,"\0\0\0"}),4,4) #if 0 // 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 // In v8.4 and later, things speed up slightly when it is omitted. ->add(PGFLUSH) #endif ;
-
} else
-
PD("Using prepared statement for %O\n", q);
+
} else
{ // Use the name from the cache
+
preparedname = tp.preparedname; // to shortcut a potential race
+
PD("Using prepared statement
%s
for %O\n",
preparedname,
q);
+
}
portal._preparedname=preparedname; if(!tp || !tp.datatypeoid) { PD("Describe statement %O\n",preparedname); if (!plugbuffer) plugbuffer = c->start(); CHAIN(plugbuffer)->add_int8('D') ->add_hstring(({'S', preparedname, 0}), 4, 4); plugbuffer->sendcmd(FLUSHSEND,portal); } else { if(plugbuffer)