Euler Taveira de Oliveira <euler@timbira.com> writes:
> Alvaro Herrera escreveu:
>> I'm not sure I'm reading this right, but isn't this preventing a
>> plpytHon function to work if parameters don't have names assigned?
> No. See the proc->argnames test before PyDict_SetItemString(). The other test
> is just tightening the check.
> Indeed, the PyDict_*ItemString() functions suffer from the same disease. :( I
> reported upstream too.
> Attached is another patch that add another test before PyDict_DelItemString();
> it's safe because if we don't have a key we don't know what to remove.
Applied, thanks, along with a regression test case. As far as I can
tell, plpython functions that have no names given for their parameters
have been broken for months, and we did not notice because whoever
added named-parameter support changed *every single* test case to use
only named parameters. Brilliant.
Alvaro's example now gives me this on Fedora 10:
ERROR: PL/Python: PL/Python function "unaccent" failed
DETAIL: <type 'exceptions.TypeError'>: normalize() argument 2 must be unicode, not str
which is the same as it did in 8.3. I do not know if that's a bug
or expected (making the database encoding be utf8 doesn't help).
Alvaro, would you see if it still crashes for you on Debian?
If so there's some other issue with python 2.5.4 ...
regards, tom lane