]> granicus.if.org Git - postgresql/commit
Clean up a number of bogosities around pltcl's handling of the Tcl "result":
authorTom Lane <tgl@sss.pgh.pa.us>
Tue, 17 Jun 2008 00:53:04 +0000 (00:53 +0000)
committerTom Lane <tgl@sss.pgh.pa.us>
Tue, 17 Jun 2008 00:53:04 +0000 (00:53 +0000)
commit6ac2529cc22a6bd770b757e60d015ebf217e4a72
treee01b97a2ccc63d73a589bcaf8f001ec0dfc24e6a
parent28afd8de10e3fbfb1caf4e4a196b3f9a3987b768
Clean up a number of bogosities around pltcl's handling of the Tcl "result":

1. Directly reading interp->result is deprecated in Tcl 8.0 and later;
you're supposed to use Tcl_GetStringResult.  This code finally broke with
Tcl 8.5, because Tcl_GetVar can now have side-effects on interp->result even
though it preserves the logical state of the result.  (There's arguably a
Tcl issue here, because Tcl_GetVar could invalidate the pointer result of a
just-preceding Tcl_GetStringResult, but I doubt the Tcl guys will see it as
a bug.)

2. We were being sloppy about the encoding of the result: some places would
push database-encoding data into the Tcl result, which should not happen,
and we were assuming that any error result coming back from Tcl was in the
database encoding, which is not a good assumption.

3. There were a lot of calls of Tcl_SetResult that uselessly specified
TCL_VOLATILE for constant strings.  This is only a minor performance issue,
but I fixed it in passing since I had to look at all the calls anyway.

#2 is a live bug regardless of which Tcl version you are interested in,
so back-patch even to branches that are unlikely to be used with Tcl 8.5.
I went back as far as 8.0, which is as far as the patch applied easily;
7.4 was using a different error processing scheme that has got its own
problems :-(
src/pl/tcl/pltcl.c