> > > So this seems to be the most clean and consistent solution:
> > >
> > > - PostgreSQL requires to be compiled with --enable-multibyte
> > > and --enable-unicode-convertion if it ought to work correctly
> > > with Tcl/Tk >= 8.1 (client or server side).
> > >
> > > - PL/Tcl needs to be changed to use pg_do_encoding_conversion
> > > if it runs on a Tcl version >= 8.1 .
> > >
> > > - PgTcl needs to be changed to set it's cliend encoding to UNICODE
> > > if it runs on a Tcl version >= 8.1 .
> > >
> > > Can we agree on that?
> >
> > yes
>
> Great!
>
> > I'll do pl/tcl part in the next version of patch. Using this
> > approach we can eliminate overhead for databases in UNICODE.
> >
> > Can somebody add tcl version checking to configure.in so we can do
> > that all on configure stage?
>
> Hmm, if we check the Tcl version at runtime instead, we could have
> PL/Tcl and PgTcl libs that don't depend on the Tcl version they run
> on. So one binary could possibly be used for all Tcl versions from 7.6
> up to 8.4 .
I'm hate tcl stubs :)) And I have tcl 8.0, 8.2 and 8.3 installed simultaneously almost anywhere and don't want
autodetect.
Yours approach ok for Pgtcl - because you load pgtcl into running tcl
interpreter, but with pl/tcl you load pltcl.so and it as dependency loads
tcl library, so stub library needs to select "best" tcl version to load :))
> The only useful change to configure.in I could think of is to issue a
> warning if configure is called without --enable-multibyte and
> --enable-unicode-convertion , but the available Tcl is >= 8.1 .
ok, for now I do it at compile time, based on TCL_MAJOR_VERSION &
TCL_MINOR_VERSION
