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

version» Context lines:

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;   }