Skip site navigation (1) Skip section navigation (2)

Re: Patch for pl/tcl Tcl_ExternalToUtf and Tcl_UtfToExternal support

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Vsevolod Lobko <seva(at)sevasoft(dot)kiev(dot)ua>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Patch for pl/tcl Tcl_ExternalToUtf and Tcl_UtfToExternal support
Date: 2001-08-23 22:48:44
Message-ID: 200108232248.f7NMmir13980@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-patches
> 
> 
> On Thu, 23 Aug 2001, Peter Eisentraut wrote:
> 
> > Vsevolod Lobko writes:
> >
> > > > Is there a way to make this automatically enabled based on the TCL
> > > > version?  Does that make sense?
> > >
> > > This adds significant overhead to pl/tcl calls :((
> > > so I'm not sure that anybody want this functionality enabled by default
> >
> > It is my understanding that Tcl 8.3 will not work with 8 bit characters
> > without this functionality.  That would simply be unacceptable.  If users
> 
> Really - yes.
> I can make this automatic based on tcl version if performance penalty on
> tcl>=8.3 is acceptable.

It is my understanding that the UTF penalty applies to all the TCL
versions >= 8.1 and that there is debate whether this is a good idea or
not.   However, seeing as TCL has the penalty, I don't see a problem
with having the same penalty in our code.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

In response to

pgsql-patches by date

Next:From: Robert B. EasterDate: 2001-08-24 01:27:54
Subject: JDBC patch (attempt#2) for util.Serialize and jdbc2.PreparedStatement
Previous:From: Vsevolod LobkoDate: 2001-08-23 22:04:21
Subject: Re: Patch for pl/tcl Tcl_ExternalToUtf and Tcl_UtfToExternal support

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group