Re: libpgtcl doesn't use UTF encoding of TCL
От | Reinhard Max |
---|---|
Тема | Re: libpgtcl doesn't use UTF encoding of TCL |
Дата | |
Msg-id | Pine.LNX.4.33.0107191214040.8261-100000@wotan.suse.de обсуждение исходный текст |
Ответ на | Re: libpgtcl doesn't use UTF encoding of TCL (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: libpgtcl doesn't use UTF encoding of TCL
Re: libpgtcl doesn't use UTF encoding of TCL |
Список | pgsql-bugs |
On Wed, 18 Jul 2001, Tom Lane wrote: > Reinhard Max <max@suse.de> writes: > > On Wed, 18 Jul 2001, Bruce Momjian wrote: > >> Do you have any idea how this will work with earlier TCL versions? > > > It won't. If pgtcl is supposed to still be able to compile with older > > versions of Tcl, the changes have to be made a compile time option. > > Please do that and resubmit the patch. OK, I'll pack the new stuff inside #ifdef TCL_UTF8 and define that if the Tcl version is 8.1 or greater. Can anybody tell me, if that TCL_ARRAYS stuff is still good for something? If I could remove it, TCL_UTF8 would be less complex at some places, because I'd only have to cover two instead of four cases. BTW, I think the proposed Patch doesn't go far enough as it assumes the database (client) encoding is identical to the system encoding by using NULL as the first argument for Tcl_UtfToExternalDString and Tcl_ExternalToUtfDString. I think it should instead either use the database's encoding for the conversion to be correct or set PostgreSQL's client encoding to UNICODE so that no conversion would be needed. Unfortunately, I don't have the time to do that at the moment. > We really don't want to give up backwards compatibility just yet. How far do you want it to be backwards compatible? If >= 8.0 is OK, I'll possibly overwork libpq later this year to use Tcl's object interface. I expect at least some performance gain out of this. cu Reinhard
В списке pgsql-bugs по дате отправления: