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

2012-04-05 Thread Jean-Baptiste Quenot
2012/4/5 Peter Eisentraut pete...@gmx.net

 On lör, 2012-03-24 at 16:24 -0400, Tom Lane wrote:
  Peter Eisentraut pete...@gmx.net writes:
   On ons, 2012-03-07 at 17:14 -0500, Tom Lane wrote:
   I said it was a reasonable alternative, not that it was the only one
   we should consider.  The behavior of .nrows() might be accidental,
   but perhaps it is a preferable model to adopt.
 
   After pondering this for several days now I still think the best
   approach is to change .nrows() to return None for utility commands and
   have the other metadata functions throw exceptions.
 
  OK, I don't have strong feelings about it.

 Well, scratch that.

 This whole area is sloppily documented.  resultset.nrows() returns
 SPI_processed, which is the number of rows, er, processed by the
 statement, which may or may not be the number of rows returned.  So a
 statement that returns no result set could very well have nrows()  0.

 The number of rows returned can be obtained by using len(resultset) (not
 documented, but one could perhaps guess it).  But len() cannot return
 None, so we cannot use that as a marker.

 The alternatives are now to introduce a new function like has_rows()
 that returns True iff result rows exist and therefore result metadata
 can be fetched, or go back to having coltypes() et al. return None when
 no metadata exists.  I'm in favor of the latter, because the former
 would add somewhat needless complications and doesn't really add any
 robustness or the like.


I consider that this is an error to request metadata when the query does
not return some.  For example: 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


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

2012-02-25 Thread Jean-Baptiste Quenot
2012/2/24 Peter Eisentraut pete...@gmx.net:
 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

 Hmm, should it be an error or just return None?  Python DB-API
 cursor.description returns None if no result set was returned.

IMO raising an error is much better because:

1) It is not a valid usecase to retrieve result metadata when no rows
are expected to be returned

2) The various metadata methods return a sequence.  Checking for null
value in this case is not a very good programming style.  I expect to
find an empty list when no data is available.

Cheers,
-- 
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


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

2012-02-10 Thread Jean-Baptiste Quenot
Dear hackers,

Thanks for the work on PLPython result metadata, it is very useful!  I
just came across a crash when trying to access this metadata on the
result of an UPDATE, which obviously cannot return any tuple (unless
you specify a RETURNING clause maybe?).

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

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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] plpython crash

2011-08-16 Thread Jean-Baptiste Quenot
After backporting plpython.c from HEAD, this is the error message I get:

ERROR:  key pg.dropped.6 not found in mapping
HINT:  To return null in a column, add the value None to the mapping
with the key named after the column.
CONTEXT:  while creating return value
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

2011-08-16 Thread Jean-Baptiste Quenot
Dear Jan,

Sorry I typed the wrong git commands.  With latest plpython from
branch master I got the same gdb backtrace as reported before.  I
managed to wrap up a testcase that fails 100% of times on my setup:
https://gist.github.com/1149512

Hope it crashes on your side too :-)

This is the 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://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] plpython crash

2011-08-12 Thread Jean-Baptiste Quenot
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://www.postgresql.org/mailpref/pgsql-hackers


[HACKERS] plpython crash

2011-08-11 Thread Jean-Baptiste Quenot
Hi there,

plpython crashes on me on various 64-bit Ubuntu hosts, see the gdb
backtrace at: https://gist.github.com/1140005

Do you believe there was recent bugfixes regarding PLyMapping_ToTuple() ?

This is PG 9.0.4 with HEAD of plpython taken in march 2011 and backported.

Please tell me if you 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


[HACKERS] Bug in plpython's Python Generators

2010-10-21 Thread Jean-Baptiste Quenot
Hi there,

I can't make Python Generators to work reliably.  According to the
documentation, this should work:

CREATE OR REPLACE FUNCTION foobar()
RETURNS SETOF text AS
$$
for s in ('Hello', 'World'):
plpy.execute('select 1')
yield s
$$
LANGUAGE 'plpythonu';

I get this error when calling the function:

test=# select foobar();
ERROR:  error fetching next item from iterator
CONTEXT:  PL/Python function foobar


When I remove the dummy plpy.execute() call, it works:

CREATE OR REPLACE FUNCTION foobar()
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.

All the best,
-- 
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


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

2010-06-18 Thread Jean-Baptiste Quenot
2010/6/17 Greg Stark gsst...@mit.edu:
 On Thu, Jun 17, 2010 at 4:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
 I actually wonder if we shouldn't automatically tag plpgsql functions
 with the search_path in effect at the time of their creation (as if
 the user had done ALTER FUNCTION ... SET search_path=...whatever the
 current search path is...).

 That would be extremely expensive and not very backwards-compatible.
 In the case at hand, just writing RETURN bar.bar(); would be the
 best-performing solution.


 I wonder if we should have a mode for plpgsql functions where all name
 lookups are done at definition time So the bar() function would be
 resolved to bar.bar() and stored that way permanently so that pg_dump
 dumped the definition as bar.bar().

 That would be probably just as 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 did in my source
code, to work around this problem.
-- 
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


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

2010-06-17 Thread Jean-Baptiste Quenot
Dear hackers,

I have a pretty nasty problem to submit to your careful scrutiny.

Please consider the following piece of SQL code:


CREATE SCHEMA bar;
SET search_path = bar;

CREATE FUNCTION bar() RETURNS text AS $$
BEGIN
RETURN 'foobar';
END
$$ LANGUAGE plpgsql IMMUTABLE;

CREATE SCHEMA foo;
SET search_path = foo;

CREATE FUNCTION foo() RETURNS text AS $$
BEGIN
RETURN bar();
END
$$ LANGUAGE plpgsql IMMUTABLE;

SET search_path = public;

CREATE TABLE foobar (d text);
insert into foobar (d) values ('foobar');

set search_path = public, foo, bar;
CREATE INDEX foobar_d on foobar using btree(foo());


Run this on a newly created database, and dump it with pg_dump. You'll
notice that the dump is unusable.  Creating a new database from this
dump will trigger the following error:

ERROR:  function bar() does not exist
LINE 1: SELECT bar()
   ^
HINT:  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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers