pike.git / lib / modules / Sql.pmod / pgsql.pike

version» Context lines:

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)