[HACKERS] Fix PL/Python metadata when there is no result

solves this issue. Instead of a PG crash, we get the following message: ERROR: plpy.Error: no result fetched All the best, -- Jean-Baptiste Quenot 0001-Fix-PLPython-metadata-access-when-there-is-no-result.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] Fix PL/Python metadata when there is no result

2012/2/24 Peter Eisentraut : > On fre, 2012-02-10 at 17:44 +0100, Jean-Baptiste Quenot wrote: >> >> Please find attached a patch that solves this issue.  Instead of a PG >> crash, we get the following message: >> >> ERROR:  plpy.Error: no result fetched >

Re: [HACKERS] Fix PL/Python metadata when there is no result

: "UPDATE mytable SET value = 1" does not return column metadata, so user is not supposed to col coltypes(). That's why I propose to return an error. coltypes() is supposed to return a sequence, not None. Checking for None is a bad coding practise IMO, especially when dealing with lists. But anyway, returning None or raising an error is still much better than crashing :-) Cheers, -- Jean-Baptiste Quenot

[HACKERS] Bug in plpython's Python Generators

RETURNS SETOF text AS $$ for s in ('Hello', 'World'): yield s $$ LANGUAGE 'plpythonu'; test=# select foobar(); foobar Hello World (2 rows) Seems like calls to plpy.execute() conflict with generators. This is the case both on versions 8.4.4 and 9.0.1. A

[HACKERS] pg_dump does not honor namespaces when functions are used in index

INT: No function matches the given name and argument types. You might need to add explicit type casts. QUERY: SELECT bar() CONTEXT: PL/pgSQL function "foo" line 2 at RETURN How can we fix this? -- Jean-Baptiste Quenot -- Sent via pgsql-hackers mailing list (pgsql-hackers@post

[HACKERS] Re: pg_dump does not honor namespaces when functions are used in index

s good as setting the search path on the > function for most users and better for some. It would have the same > problem with dynamic sql that a lot of things have though. +1 IMHO PG should dump the bar() function call as bar.bar() to be safe. Using fully qualified function name is what I d

[HACKERS] plpython crash

need more information. -- Jean-Baptiste Quenot -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] plpython crash

Here is the same with -O0: https://gist.github.com/1140005 sys.version reports this: INFO: 2.6.6 (r266:84292, Sep 15 2010, 16:41:53) [GCC 4.4.5] -- Jean-Baptiste Quenot -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] plpython crash

PL/Python function "myfunc" What does it mean? -- Jean-Baptiste Quenot -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] plpython crash

result on PG 9.0.4: https://gist.github.com/1149543 This is the result on PG 9.0.4 with plpython.c backported from HEAD: https://gist.github.com/1149558 Cheers, -- Jean-Baptiste Quenot -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http