Re: invalid UTF-8 via pl/perl
От | Andrew Dunstan |
---|---|
Тема | Re: invalid UTF-8 via pl/perl |
Дата | |
Msg-id | 4B40A98D.6000307@dunslane.net обсуждение исходный текст |
Ответ на | Re: invalid UTF-8 via pl/perl (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: invalid UTF-8 via pl/perl
(Tom Lane <tgl@sss.pgh.pa.us>)
Re: invalid UTF-8 via pl/perl (Andrew Dunstan <andrew@dunslane.net>) |
Список | pgsql-hackers |
Andrew Dunstan wrote: > > > Andrew Dunstan wrote: >> >> I think the plperl glue code should check returned strings using >> pg_verifymbstr(). >> >> > > Please test this patch. I think we'd probably want to trap the > encoding error and issue a customised error message, but this plugs > all the holes I can see with the possible exception of values inserted > via SPI calls. I'll check that out. > > I think the attached patch plugs the direct SPI holes as well. One thing that I am pondering is: how does SPI handle things if the client encoding and server encoding are not the same? Won't the strings it passes the parser be interpreted in the client encoding? If so, that doesn't seem right at all, since these strings come from a server side call and not from the client at all. It looks to me like the call to pg_parse_query() in spi.c should possibly be surrounded by code to temporarily set the client encoding to the server encoding and then restore it afterwards. cheers andrew Index: src/pl/plperl/plperl.c =================================================================== RCS file: /cvsroot/pgsql/src/pl/plperl/plperl.c,v retrieving revision 1.157 diff -c -r1.157 plperl.c *** src/pl/plperl/plperl.c 31 Dec 2009 19:41:37 -0000 1.157 --- src/pl/plperl/plperl.c 3 Jan 2010 14:12:25 -0000 *************** *** 630,636 **** errmsg("Perl hash contains nonexistent column \"%s\"", key))); if (SvOK(val)) ! values[attn - 1] = SvPV(val, PL_na); } hv_iterinit(perlhash); --- 630,642 ---- errmsg("Perl hash contains nonexistent column \"%s\"", key))); if (SvOK(val)) ! { ! char * aval; ! ! aval = SvPV(val, PL_na); ! pg_verifymbstr(aval, strlen(aval), false); ! values[attn - 1] = aval; ! } } hv_iterinit(perlhash); *************** *** 829,836 **** atttypmod = tupdesc->attrs[attn - 1]->atttypmod; if (SvOK(val)) { modvalues[slotsused] = InputFunctionCall(&finfo, ! SvPV(val, PL_na), typioparam, atttypmod); modnulls[slotsused] = ' '; --- 835,846 ---- atttypmod = tupdesc->attrs[attn - 1]->atttypmod; if (SvOK(val)) { + char * aval; + + aval = SvPV(val, PL_na); + pg_verifymbstr(aval,strlen(aval), false); modvalues[slotsused] = InputFunctionCall(&finfo, ! aval, typioparam, atttypmod); modnulls[slotsused] = ' '; *************** *** 1468,1474 **** } val = SvPV(perlret, PL_na); ! retval = InputFunctionCall(&prodesc->result_in_func, val, prodesc->result_typioparam, -1); } --- 1478,1484 ---- } val = SvPV(perlret, PL_na); ! pg_verifymbstr(val, strlen(val), false); retval = InputFunctionCall(&prodesc->result_in_func, val, prodesc->result_typioparam, -1); } *************** *** 2125,2131 **** } val = SvPV(sv, PL_na); ! ret = InputFunctionCall(&prodesc->result_in_func, val, prodesc->result_typioparam, -1); isNull = false; --- 2135,2141 ---- } val = SvPV(sv, PL_na); ! pg_verifymbstr(val, strlen(val), false); ret = InputFunctionCall(&prodesc->result_in_func, val, prodesc->result_typioparam, -1); isNull = false; *************** *** 2516,2523 **** { if (SvOK(argv[i])) { argvalues[i] = InputFunctionCall(&qdesc->arginfuncs[i], ! SvPV(argv[i], PL_na), qdesc->argtypioparams[i], -1); nulls[i] = ' '; --- 2526,2537 ---- { if (SvOK(argv[i])) { + char *val; + + val = SvPV(argv[i], PL_na); + pg_verifymbstr(val, strlen(val), false); argvalues[i] = InputFunctionCall(&qdesc->arginfuncs[i], ! val, qdesc->argtypioparams[i], -1); nulls[i] = ' '; *************** *** 2647,2652 **** --- 2661,2669 ---- { if (SvOK(argv[i])) { + char *val; + + pg_verifymbstr(val, strlen(val), false); argvalues[i] = InputFunctionCall(&qdesc->arginfuncs[i], SvPV(argv[i], PL_na), qdesc->argtypioparams[i],
В списке pgsql-hackers по дате отправления:
Следующее
От: Robert HaasДата:
Сообщение: Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns