Re: pltcl broken on tcl8.5 ?
От | Tom Lane |
---|---|
Тема | Re: pltcl broken on tcl8.5 ? |
Дата | |
Msg-id | 8838.1213656734@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pltcl broken on tcl8.5 ? (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: pltcl broken on tcl8.5 ?
|
Список | pgsql-hackers |
Andrew Dunstan <andrew@dunslane.net> writes: > Tom Lane wrote: >> Hoo, nasty. Tcl_GetVar() is resetting interp->result. > According to the manual page that's only supposed to happen if the > TCL_LEAVE_ERR_MSG flag is used: > TCL_LEAVE_ERR_MSG > If an error is returned and this bit is set in flags, then an > error message will be left in the interpreter�s result, where it > can be retrieved with Tcl_GetObjResult or Tcl_GetStringResult. > If this flag bit isn�t set then no error message is left and the > interpreter�s result will not be modified. But notice that they specify using Tcl_GetObjResult or Tcl_GetStringResult, rather than touching the field directly. I suspect they'd regard this as not-a-bug. In any case I found the responsible code: Tcl_SaveInterpState/Tcl_RestoreInterpState restore the result as an object not a string. I see no such routines in 8.4. As I look at this, I think it's got even more problems: it's assuming that interp->result is in the database encoding, which seems a pretty faulty assumption considering it came from Tcl. pltcl_elog converts to the database encoding before calling Tcl_SetResult, which makes that path all right as long as Tcl doesn't do anything with the string before exiting, but I don't particularly trust that assumption either. All in all this is really quite broken. regards, tom lane
В списке pgsql-hackers по дате отправления: