Victor Wagner <vitus@wagner.pp.ru> writes:
> On Mon, 22 Feb 2016 17:57:36 -0600
> Jim Nasby <Jim.Nasby@BlueTreble.com> wrote:
>> Is there any backwards compatibility risk to these changes? Could
>> having that new info break someone's existing code?
> I don't think so. ErrorCode and ErrorInfo mechanisms present in the Tcl
> for ages. As far as I remember, it predates Tcl_Obj API. Unfortunately
> I've lost my copy of 2-nd edition of "Practical Programming on Tcl/Tk"
> and have only 4-th edition handy, so it's quite hard to dig out Tcl 7.6
> docs.
I've got some dead-tree Tcl 7.3 documentation that describes those
functions, so for sure we can rely on them if we're going to rely on
Tcl objects.
Speaking of which, I wonder if this isn't a good time to move the
goalposts a little further in terms of which Tcl versions we support.
Tcl 8.4 was released in 2002; does anybody really think that someone
would try to use Postgres 9.6+ with a Tcl older than that? If we
just said "8.4 is the minimum", we could get rid of a number of #if's
in pltcl.c. I also note the comment in front of one of those #if's:
/** Hack to override Tcl's builtin Notifier subsystem. This prevents the* backend from becoming multithreaded, which
breaksall sorts of things.* ...* We can only fix this with Tcl >= 8.4, when Tcl_SetNotifier() appeared.*/
In other words, if you run PG with a pre-8.4 version of Tcl, you're at
very serious risk of breakage.
Also, AFAICT we have no buildfarm members testing anything older than
8.4, so it's pretty hypothetical whether it'd even still work at all.
So I propose that we remove those #if's in favor of something like this
near the top:
#if !HAVE_TCL_VERSION(8,4)
#error PostgreSQL only supports Tcl 8.4 or later.
#endif
If we don't do that, I'm at least going to put in a similar #error for
Tcl 8.0; but I really think we ought to just say 8.4 is the minimum.
regards, tom lane
