> can you please change your patch to fix offending make-local-name (i guess
> it should intern name into keyword package rather than doing this
> read-from-string thing)
> rather than innocent users of that symbol?
Sure, never wanted to harm them anyway ;) Attached.
LeslieWed Apr 30 14:10:24 C
LPP> ...
LPP> 1: (DB-POSTMODERN::ENSURE-PREPARED-ON-CONNECTION
LPP> COMMON-LISP-USER::TREE10SELECT "TREE10SELECT"
LPP> ^^
LPP> "select bob from tree10,blob where qi=$1 and bid = value")
LPP> 2: (CL-POSTGRES:CONNECTION-META
LPP>
> also, it's not clear what happens if transaction is rolled back -- is
> prepared statement rolled back too, or it is memorized?
> it seems this way our idea of memorized statements and db session can be
> desynchronized, but actually in _oposite direction_: our code will think
> that it's there,
??>> but are you sure that restarting txn in this case is right, and when
??>> such stuff happens at all?
LPP> Heh, if you ask me the best solution would be if Postgres
LPP> just shut up about it without affecting the txn.
LPP> But alas, this isn't the case.
hmm, postgres documentation says:
> LPP> What can I do about it with the new Postmodern code?
>
> hmm, iirc this error was addressed in executor-exec-prepared in pm-sql.lisp,
> but you moved it into pm-transaction.lisp to restart txn in case of this
> error, right?
Yes.
> and then i've removed it when merging, sorry..
>
> if s
LPP> What can I do about it with the new Postmodern code?
hmm, iirc this error was addressed in executor-exec-prepared in pm-sql.lisp,
but you moved it into pm-transaction.lisp to restart txn in case of this
error, right?
and then i've removed it when merging, sorry..
if so, add it into into p
