Обсуждение: pltcl bug in 7.2?
Hello All,
We have a database with koi8-r encoding, tables and fields names
mostly in russian, and we have a trigger function on pltcl. With postgresql 7.1 everything
worked well, but in 7.2 we are getting an error "utf_to_local: could
not convert UTF-8" in the following construction
foreach field [array names NEW] {
if {[info exists OLD(${field})]} ....
Also this error occures in any calling of NEW or OLD, for example
[array get NEW] also raises those error.
--
Best regards,
Yury Don
Yury Don <yura@vpcit.ru> writes:
> Hello All,
> We have a database with koi8-r encoding, tables and fields names
> mostly in russian, and we have a trigger function on pltcl. With postgresql 7.1 everything
> worked well, but in 7.2 we are getting an error "utf_to_local: could
> not convert UTF-8" in the following construction
> foreach field [array names NEW] {
> if {[info exists OLD(${field})]} ....
Hmm. Someone added code in 7.2 to support conversion between the
database's encoding (whatever you specified with -E) and the UTF-8
encoding that Tcl wants to use all the time. Sounds like you've
found a bug in that code.
> Also this error occures in any calling of NEW or OLD, for example
> [array get NEW] also raises those error.
Do you see it *only* in references to NEW/OLD? Can you pass the
same data in normal parameters to a Tcl function?
regards, tom lane
array get NEW seems to work fine in 7.2.1
This trigger function below works fine
CREATE OR REPLACE FUNCTION networks_sort_trigger_func() RETURNS OPAQUE AS
'
set sort "0/"
if { [info exists NEW(parent_id)] && $NEW(parent_id) != "" } {
spi_exec "SELECT sp_go_up_network_tree($NEW(parent_id)) AS
parent_list"
for { set x [expr [llength $parent_list] - 1] } { $x >= 0 } { incr x
-1 } {
append sort "[lindex $parent_list $x]/"
}
}
append sort "$NEW(network_id)/"
spi_exec "UPDATE inv_network
SET sort = ''$sort''
WHERE network_id = $NEW(network_id)"
return [array get NEW]
END;' LANGUAGE 'pltcl';
DROP TRIGGER networks_sort_trigger ON inv_network;
CREATE TRIGGER networks_sort_trigger AFTER INSERT ON inv_network
FOR EACH ROW EXECUTE PROCEDURE networks_sort_trigger_func();
But it does not use UTF-8
Darren Ferguson
On Fri, 19 Apr 2002, Tom Lane wrote:
> Yury Don <yura@vpcit.ru> writes:
> > Hello All,
> > We have a database with koi8-r encoding, tables and fields names
> > mostly in russian, and we have a trigger function on pltcl. With postgresql 7.1 everything
> > worked well, but in 7.2 we are getting an error "utf_to_local: could
> > not convert UTF-8" in the following construction
> > foreach field [array names NEW] {
> > if {[info exists OLD(${field})]} ....
>
> Hmm. Someone added code in 7.2 to support conversion between the
> database's encoding (whatever you specified with -E) and the UTF-8
> encoding that Tcl wants to use all the time. Sounds like you've
> found a bug in that code.
>
> > Also this error occures in any calling of NEW or OLD, for example
> > [array get NEW] also raises those error.
>
> Do you see it *only* in references to NEW/OLD? Can you pass the
> same data in normal parameters to a Tcl function?
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>
Darren Ferguson <darren@crystalballinc.com> writes:
> array get NEW seems to work fine in 7.2.1
So we ought to ask what's the difference between your situation and
Yuri's. Do you even have multibyte support compiled? If so, what
database encoding are you using? Which Tcl version are you using?
regards, tom lane
Multibyte is compiled, No db encoding just use ASCII tables TCL version 8.3 HTH Darren Ferguson On Fri, 19 Apr 2002, Tom Lane wrote: > Darren Ferguson <darren@crystalballinc.com> writes: > > array get NEW seems to work fine in 7.2.1 > > So we ought to ask what's the difference between your situation and > Yuri's. Do you even have multibyte support compiled? If so, what > database encoding are you using? Which Tcl version are you using? > > regards, tom lane >
Hello Tom,
Friday, April 19, 2002, 8:32:16 PM, you wrote:
TL> Yury Don <yura@vpcit.ru> writes:
>> Hello All,
>> We have a database with koi8-r encoding, tables and fields names
>> mostly in russian, and we have a trigger function on pltcl. With postgresql 7.1 everything
>> worked well, but in 7.2 we are getting an error "utf_to_local: could
>> not convert UTF-8" in the following construction
>> foreach field [array names NEW] {
>> if {[info exists OLD(${field})]} ....
TL> Hmm. Someone added code in 7.2 to support conversion between the
TL> database's encoding (whatever you specified with -E) and the UTF-8
TL> encoding that Tcl wants to use all the time. Sounds like you've
TL> found a bug in that code.
>> Also this error occures in any calling of NEW or OLD, for example
>> [array get NEW] also raises those error.
TL> Do you see it *only* in references to NEW/OLD? Can you pass the
TL> same data in normal parameters to a Tcl function?
TL> regards, tom lane
I can see this error only in trigger functions when I call NEW or OLD
and trigger table has a fields with names containing cyrillic characters.
Any other variables, parameters, with cyrillic characters don't raise
this error. For example following code works well (relname contains cyrillic characters):
spi_exec "SELECT relname FROM pg_class WHERE oid=$TG_relid"
elog DEBUG "$relname"
This code also works without errors:
CREATE or replace FUNCTION tmp1(text) RETURNS text AS '
return $1
}
' LANGUAGE 'pltcl';
select tmp1('<here some text with cyrillic characters>');
But the following code raises an error "utf_to_local: could not convert
UTF-8" (trigger table has a fields with names containing cyrillic characters)
CREATE or replace FUNCTION log_event() RETURNS opaque AS '
foreach field [array names NEW] {
elog DEBUG "field=$field"
}
return OK
}
' LANGUAGE 'pltcl';
And in postgresql.log I see strings
field=<field name>
for fields whose names consist of only latin characters and string
field=
for fields whose names include cyrillic characters
Postgres 7.2.1 on Debian Linux, compiled with --enable-multibyte,
--enable-unicode-conversion, --enable-locale. Tcl version 8.3.
--
Best regards,
Yury mailto:yura@vpcit.ru
Hello Tom,
Friday, April 19, 2002, 8:32:16 PM, you wrote:
TL> Yury Don <yura@vpcit.ru> writes:
>> Hello All,
>> We have a database with koi8-r encoding, tables and fields names
>> mostly in russian, and we have a trigger function on pltcl. With postgresql 7.1 everything
>> worked well, but in 7.2 we are getting an error "utf_to_local: could
>> not convert UTF-8" in the following construction
>> foreach field [array names NEW] {
>> if {[info exists OLD(${field})]} ....
TL> Hmm. Someone added code in 7.2 to support conversion between the
TL> database's encoding (whatever you specified with -E) and the UTF-8
TL> encoding that Tcl wants to use all the time. Sounds like you've
TL> found a bug in that code.
I've removed conversion between the database's encoding by changing in
pltcl.c
#if defined(UNICODE_CONVERSION) && TCL_MAJOR_VERSION == 8 \
to
#if defined(UNICODE_CONVERSION_1) && TCL_MAJOR_VERSION == 8 \
and after that an error have disappeared and everything works well.
--
Best regards,
Yury mailto:yura@vpcit.ru
Should this patch be included in our code?
---------------------------------------------------------------------------
Yury Don wrote:
> Hello Tom,
>
> Friday, April 19, 2002, 8:32:16 PM, you wrote:
>
> TL> Yury Don <yura@vpcit.ru> writes:
> >> Hello All,
> >> We have a database with koi8-r encoding, tables and fields names
> >> mostly in russian, and we have a trigger function on pltcl. With postgresql 7.1 everything
> >> worked well, but in 7.2 we are getting an error "utf_to_local: could
> >> not convert UTF-8" in the following construction
> >> foreach field [array names NEW] {
> >> if {[info exists OLD(${field})]} ....
>
> TL> Hmm. Someone added code in 7.2 to support conversion between the
> TL> database's encoding (whatever you specified with -E) and the UTF-8
> TL> encoding that Tcl wants to use all the time. Sounds like you've
> TL> found a bug in that code.
>
> I've removed conversion between the database's encoding by changing in
> pltcl.c
> #if defined(UNICODE_CONVERSION) && TCL_MAJOR_VERSION == 8 \
> to
> #if defined(UNICODE_CONVERSION_1) && TCL_MAJOR_VERSION == 8 \
> and after that an error have disappeared and everything works well.
>
> --
> Best regards,
> Yury mailto:yura@vpcit.ru
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Should this patch be included in our code?
It looked to me like this wasn't a fix, but a deliberate cutting-out of
functionality that Yury happened not to need. Someone needs to take the
time to understand the actual bug and propose a proper fix.
I have already made one post-7.2 fix in pltcl's UTF conversion, but
I do not believe it explains Yury's report.
regards, tom lane