Re: [HACKERS] PL/Python: Add cursor and execute methods to plan object

On 3/22/17 11:46, Andrew Dunstan wrote: > This is a very simple patch that does what it advertises. It applies > cleanly and provides tests for both the new methods (plan.cursor and > plan.execute). > > Marking Ready For Committer. committed -- Peter Eisentraut http://www.2ndQuadra

Re: [HACKERS] PL/Python: Add cursor and execute methods to plan object

Jim Nasby writes: > On 2/25/17 10:27 AM, Peter Eisentraut wrote: >> So I'm also wondering here which style people prefer so >> I can implement it there. > > I think the more OO style is definitely better. I expect it would > simplify the code as well. I'm not a Python person, but I'd argue that

Re: [HACKERS] PL/Python: Add cursor and execute methods to plan object

On 2/25/17 10:27 AM, Peter Eisentraut wrote: So I'm also wondering here which style people prefer so I can implement it there. I think the more OO style is definitely better. I expect it would simplify the code as well. -- Jim C. Nasby, Data Architect j...@nasby.net 512.

Re: [HACKERS] PL/Python: Add cursor and execute methods to plan object

On 03/21/2017 06:27 PM, Andrew Dunstan wrote: > On 03/16/2017 05:32 PM, David Steele wrote: >> On 2/25/17 1:27 PM, Peter Eisentraut wrote: >>> Something that has been bothering me in PL/Python for a long time is the >>> non-object-oriented way in which plans are prepared and executed: >>> >>>

Re: [HACKERS] PL/Python: Add cursor and execute methods to plan object

On 03/16/2017 05:32 PM, David Steele wrote: > On 2/25/17 1:27 PM, Peter Eisentraut wrote: >> Something that has been bothering me in PL/Python for a long time is the >> non-object-oriented way in which plans are prepared and executed: >> >> plan = plpy.prepare(...) >> res = plpy.execute(p

Re: [HACKERS] PL/Python: Add cursor and execute methods to plan object

On 2/25/17 1:27 PM, Peter Eisentraut wrote: > Something that has been bothering me in PL/Python for a long time is the > non-object-oriented way in which plans are prepared and executed: > > plan = plpy.prepare(...) > res = plpy.execute(plan, ...) > > where plpy.execute() takes either a p

[HACKERS] PL/Python: Add cursor and execute methods to plan object

Something that has been bothering me in PL/Python for a long time is the non-object-oriented way in which plans are prepared and executed: plan = plpy.prepare(...) res = plpy.execute(plan, ...) where plpy.execute() takes either a plan or a query string. I think a better style would be

Re: [HACKERS] PL/Python adding support for multi-dimensional arrays

2016-10-26 10:03 GMT+02:00 Heikki Linnakangas : > On 10/24/2016 10:33 PM, Pavel Stehule wrote: > >> Hi >> >> 2016-10-14 10:53 GMT+02:00 Heikki Linnakangas : >> >> Please review. Are the docs and the error messages now clear enough on >>> this? We'll need a mention in the release notes too, when it

Re: [HACKERS] PL/Python adding support for multi-dimensional arrays

On 10/24/2016 10:33 PM, Pavel Stehule wrote: Hi 2016-10-14 10:53 GMT+02:00 Heikki Linnakangas : Please review. Are the docs and the error messages now clear enough on this? We'll need a mention in the release notes too, when it's time for that. The error message is clear. Ok, great! I te

Re: [HACKERS] PL/Python adding support for multi-dimensional arrays

Hi 2016-10-14 10:53 GMT+02:00 Heikki Linnakangas : > On 10/11/2016 08:56 AM, Pavel Stehule wrote: > >> 2016-10-11 7:49 GMT+02:00 Heikki Linnakangas : >> >> Unfortunately there are cases that are fundamentally ambiguous. >>> >>> create type comptype as (intarray int[]); >>> create function array_r

Re: [HACKERS] PL/Python adding support for multi-dimensional arrays

On 14 October 2016 19:18:01 EEST, Jim Nasby wrote: >On 10/14/16 3:53 AM, Heikki Linnakangas wrote: >> Composite types in arrays must now be returned as >> Python tuples, not lists, to resolve the ambiguity. I.e. "[(col1, >col2), >> (col1, col2)]". > >Shouldn't dicts be allowed as well? Ah yes,

Re: [HACKERS] PL/Python adding support for multi-dimensional arrays

On 10/14/16 3:53 AM, Heikki Linnakangas wrote: Composite types in arrays must now be returned as Python tuples, not lists, to resolve the ambiguity. I.e. "[(col1, col2), (col1, col2)]". Shouldn't dicts be allowed as well? I'm not sure they would automatically be considered as tuples (unlike so

Re: [HACKERS] PL/Python adding support for multi-dimensional arrays

On 10/11/2016 08:56 AM, Pavel Stehule wrote: 2016-10-11 7:49 GMT+02:00 Heikki Linnakangas : Unfortunately there are cases that are fundamentally ambiguous. create type comptype as (intarray int[]); create function array_return() returns comptype[] as $$ return 1; $$ language plpython

Re: [HACKERS] PL/Python adding support for multi-dimensional arrays

2016-10-11 7:49 GMT+02:00 Heikki Linnakangas : > On 10/10/2016 08:42 PM, Pavel Stehule wrote: > >> 2016-10-10 12:31 GMT+02:00 Heikki Linnakangas : >> >> On 10/01/2016 02:45 AM, Jim Nasby wrote: >>> >>> On 9/29/16 1:51 PM, Heikki Linnakangas wrote: Now, back to multi-dimensional arrays. I

Re: [HACKERS] PL/Python adding support for multi-dimensional arrays

On 10/10/2016 08:42 PM, Pavel Stehule wrote: 2016-10-10 12:31 GMT+02:00 Heikki Linnakangas : On 10/01/2016 02:45 AM, Jim Nasby wrote: On 9/29/16 1:51 PM, Heikki Linnakangas wrote: Now, back to multi-dimensional arrays. I can see that the Sequence representation is problematic, with arrays,

Re: [HACKERS] PL/Python adding support for multi-dimensional arrays

On 10 October 2016 at 13:42, Pavel Stehule wrote: > > > 2016-10-10 12:31 GMT+02:00 Heikki Linnakangas : > >> On 10/01/2016 02:45 AM, Jim Nasby wrote: >> >>> On 9/29/16 1:51 PM, Heikki Linnakangas wrote: >>> Now, back to multi-dimensional arrays. I can see that the Sequence representatio

Re: [HACKERS] PL/Python adding support for multi-dimensional arrays

2016-10-10 12:31 GMT+02:00 Heikki Linnakangas : > On 10/01/2016 02:45 AM, Jim Nasby wrote: > >> On 9/29/16 1:51 PM, Heikki Linnakangas wrote: >> >>> Now, back to multi-dimensional arrays. I can see that the Sequence >>> representation is problematic, with arrays, because if you have a python >>> l

Re: [HACKERS] PL/Python adding support for multi-dimensional arrays

On 10/01/2016 02:45 AM, Jim Nasby wrote: On 9/29/16 1:51 PM, Heikki Linnakangas wrote: Now, back to multi-dimensional arrays. I can see that the Sequence representation is problematic, with arrays, because if you have a python list of lists, like [[1, 2]], it's not immediately clear if that's a

Re: [HACKERS] PL/Python adding support for multi-dimensional arrays

On Sat, Oct 1, 2016 at 8:45 AM, Jim Nasby wrote: > On 9/29/16 1:51 PM, Heikki Linnakangas wrote: >> >> Jim, I was confused, but you agreed with me. Were you also confused, or >> am I missing something? > > > I was confused by inputs: I have marked the patch as returned with feedback. Or Heikki, d

Re: [HACKERS] PL/Python adding support for multi-dimensional arrays

On 9/29/16 1:51 PM, Heikki Linnakangas wrote: Jim, I was confused, but you agreed with me. Were you also confused, or am I missing something? I was confused by inputs: CREATE FUNCTION repr(i foo[]) RETURNS text LANGUAGE plpythonu AS $$return repr(i)$$; select repr(array[row(1,2)::foo, row(3,

Re: [HACKERS] PL/Python adding support for multi-dimensional arrays

On 09/23/2016 10:27 PM, Jim Nasby wrote: On 9/23/16 2:42 AM, Heikki Linnakangas wrote: How do we handle single-dimensional arrays of composite types at the moment? At a quick glance, it seems that the composite types are just treated like strings, when they're in an array. That's probably OK, bu

Re: [HACKERS] PL/Python adding support for multi-dimensional arrays

On 27 September 2016 at 14:58, Heikki Linnakangas wrote: > On 09/27/2016 02:04 PM, Dave Cramer wrote: > >> On 26 September 2016 at 14:52, Dave Cramer wrote: >> >>> This crashes with arrays with non-default lower bounds: postgres=# SELECT * FROM test_type_conversion_array_int 4('[2

Re: [HACKERS] PL/Python adding support for multi-dimensional arrays

On 09/27/2016 02:04 PM, Dave Cramer wrote: On 26 September 2016 at 14:52, Dave Cramer wrote: This crashes with arrays with non-default lower bounds: postgres=# SELECT * FROM test_type_conversion_array_int 4('[2:4]={1,2,3}'); INFO: ([1, 2, ], ) server closed the connection unexpectedly

Re: [HACKERS] PL/Python adding support for multi-dimensional arrays

On 26 September 2016 at 14:52, Dave Cramer wrote: > > > >> >> This crashes with arrays with non-default lower bounds: >> >> postgres=# SELECT * FROM test_type_conversion_array_int >> 4('[2:4]={1,2,3}'); >> INFO: ([1, 2, ], ) >> server closed the connection unexpectedly >> This probably m

Re: [HACKERS] PL/Python adding support for multi-dimensional arrays

> > This crashes with arrays with non-default lower bounds: > > postgres=# SELECT * FROM test_type_conversion_array_int4('[2:4]={1,2,3}'); > INFO: ([1, 2, ], ) > server closed the connection unexpectedly > This probably means the server terminated abnormally > before or while proce

Re: [HACKERS] PL/Python adding support for multi-dimensional arrays

On 9/23/16 2:42 AM, Heikki Linnakangas wrote: How do we handle single-dimensional arrays of composite types at the moment? At a quick glance, it seems that the composite types are just treated like strings, when they're in an array. That's probably OK, but it means that there's nothing special ab

Re: [HACKERS] PL/Python adding support for multi-dimensional arrays

On 09/22/2016 10:28 AM, Pavel Stehule wrote: Now, the tests are enough - so I'll mark this patch as ready for commiters. I had to fix tests - there was lot of white spaces, and the result for python3 was missing Thanks Pavel! This crashes with arrays with non-default lower bounds: postgres=#

Re: [HACKERS] PL/Python adding support for multi-dimensional arrays

Hi 2016-09-21 19:53 GMT+02:00 Dave Cramer : > > On 18 September 2016 at 09:27, Dave Cramer wrote: > >> >> On 10 August 2016 at 01:53, Pavel Stehule >> wrote: >> >>> Hi >>> >>> 2016-08-03 13:54 GMT+02:00 Alexey Grishchenko : >>> On Wed, Aug 3, 2016 at 12:49 PM, Alexey Grishchenko < agr

Re: [HACKERS] PL/Python adding support for multi-dimensional arrays

On 18 September 2016 at 09:27, Dave Cramer wrote: > > On 10 August 2016 at 01:53, Pavel Stehule wrote: > >> Hi >> >> 2016-08-03 13:54 GMT+02:00 Alexey Grishchenko : >> >>> On Wed, Aug 3, 2016 at 12:49 PM, Alexey Grishchenko < >>> agrishche...@pivotal.io> wrote: >>> Hi Current impl

Re: [HACKERS] PL/Python adding support for multi-dimensional arrays

On 10 August 2016 at 01:53, Pavel Stehule wrote: > Hi > > 2016-08-03 13:54 GMT+02:00 Alexey Grishchenko : > >> On Wed, Aug 3, 2016 at 12:49 PM, Alexey Grishchenko < >> agrishche...@pivotal.io> wrote: >> >>> Hi >>> >>> Current implementation of PL/Python does not allow the use of >>> multi-dimensi

Re: [HACKERS] PL/Python adding support for multi-dimensional arrays

Hi 2016-08-03 13:54 GMT+02:00 Alexey Grishchenko : > On Wed, Aug 3, 2016 at 12:49 PM, Alexey Grishchenko < > agrishche...@pivotal.io> wrote: > >> Hi >> >> Current implementation of PL/Python does not allow the use of >> multi-dimensional arrays, for both input and output parameters. This forces >

Re: [HACKERS] PL/Python adding support for multi-dimensional arrays

On Wed, Aug 3, 2016 at 12:49 PM, Alexey Grishchenko wrote: > Hi > > Current implementation of PL/Python does not allow the use of > multi-dimensional arrays, for both input and output parameters. This forces > end users to introduce workarounds like casting arrays to text before > passing them to

[HACKERS] PL/Python adding support for multi-dimensional arrays

Hi Current implementation of PL/Python does not allow the use of multi-dimensional arrays, for both input and output parameters. This forces end users to introduce workarounds like casting arrays to text before passing them to the functions and parsing them after, which is an error-prone approach

Re: [HACKERS] PL/Python: domain over array support

On 11/27/13 14:15, Marko Kreen wrote: On Tue, Nov 26, 2013 at 07:12:00PM -0200, Rodolfo Campero wrote: 2013/11/26 Heikki Linnakangas Oops, sorry about that. Fixed. Maybe be you forgot to modify plpython_types_3.out Yes. Heikki, please fix plpython_types_3.out too. See attached patch. A

Re: [HACKERS] PL/Python: domain over array support

On Tue, Nov 26, 2013 at 07:12:00PM -0200, Rodolfo Campero wrote: > 2013/11/26 Heikki Linnakangas > > Oops, sorry about that. Fixed. > > Maybe be you forgot to modify > plpython_types_3.out Yes. Heikki, please fix plpython_types_3.out too. See attached patch. -- marko diff --git a/src/pl/plp

Re: [HACKERS] PL/Python: domain over array support

2013/11/26 Heikki Linnakangas > On 11/26/13 19:07, Kevin Grittner wrote: > >> Heikki Linnakangas wrote: >> >> Ok, committed. >>> >> >> make check-world failure: >> > > Oops, sorry about that. Fixed. Maybe be you forgot to modify plpython_types_3.out

Re: [HACKERS] PL/Python: domain over array support

On 11/26/13 19:07, Kevin Grittner wrote: Heikki Linnakangas wrote: Ok, committed. make check-world failure: Oops, sorry about that. Fixed. - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailp

Re: [HACKERS] PL/Python: domain over array support

Heikki Linnakangas wrote: > Ok, committed. make check-world failure: *** /home/kgrittn/pg/master/src/pl/plpython/expected/plpython_types.out 2013-11-26 10:52:04.173441894 -0600 --- /home/kgrittn/pg/master/src/pl/plpython/results/plpython_types.out  2013-11-26 10:55:58.229445970 -0600

Re: [HACKERS] PL/Python: domain over array support

On 11/26/13 11:56, Marko Kreen wrote: On Tue, Nov 26, 2013 at 12:23:48AM +0200, Heikki Linnakangas wrote: The new behavior is clearly better, but it is an incompatibility nonetheless. I don't do anything with PL/python myself, so I don't have a good feel of how much that'll break people's applic

Re: [HACKERS] PL/Python: domain over array support

On Tue, Nov 26, 2013 at 12:23:48AM +0200, Heikki Linnakangas wrote: > The new behavior is clearly better, but it is an incompatibility > nonetheless. I don't do anything with PL/python myself, so I don't > have a good feel of how much that'll break people's applications. > Probably not much I guess

Re: [HACKERS] PL/Python: domain over array support

2013/11/25 Heikki Linnakangas [...] > This does change the behavior of any existing functions that return a > domain over array. For example: > > postgres=# create domain intarr as integer[]; > CREATE DOMAIN > postgres=# create function intarr_test() returns intarr as $$ > return '{1,2}' > $$ lan

Re: [HACKERS] PL/Python: domain over array support

On 24.11.2013 18:44, Marko Kreen wrote: On Sat, Nov 23, 2013 at 11:09:53AM -0200, Rodolfo Campero wrote: 2013/11/22 Marko Kreen One more thing - please update Python 3 regtests too. The attached patch (version 3) includes the expected results for Python 3 (file plpython_types_3.out). Thank

Re: [HACKERS] PL/Python: domain over array support

Thank you very much Marko. 2013/11/24 Marko Kreen > On Sat, Nov 23, 2013 at 11:09:53AM -0200, Rodolfo Campero wrote: > > 2013/11/22 Marko Kreen > > > One more thing - please update Python 3 regtests too. > > > > > The attached patch (version 3) includes the expected results for Python 3 > > (f

Re: [HACKERS] PL/Python: domain over array support

On Sat, Nov 23, 2013 at 11:09:53AM -0200, Rodolfo Campero wrote: > 2013/11/22 Marko Kreen > > One more thing - please update Python 3 regtests too. > > > The attached patch (version 3) includes the expected results for Python 3 > (file plpython_types_3.out). Thanks. Looks good now. Tagging as r

Re: [HACKERS] PL/Python: domain over array support

2013/11/22 Marko Kreen > > One more thing - please update Python 3 regtests too. > > The attached patch (version 3) includes the expected results for Python 3 (file plpython_types_3.out). diff --git a/src/pl/plpython/expected/plpython_types.out b/src/pl/plpython/expected/plpython_types.out index

Re: [HACKERS] PL/Python: domain over array support

On Fri, Nov 22, 2013 at 08:45:56AM -0200, Rodolfo Campero wrote: > There are other cosmetic changes in this patch, wrt previous version (not > preexistent code): > * adjusted alignment of variable name "rv" in line 12 > * reworded comment in line 850, resulting in more than 80 characters, so I >

Re: [HACKERS] PL/Python: domain over array support

Marko, 2013/11/22 Marko Kreen > On Sat, Oct 26, 2013 at 11:17:19AM -0200, Rodolfo Campero wrote: > > The attached patch add support of domains over arrays to PL/Python (eg: > > CREATE DOMAIN my_domain AS integer[]). > > > > Basically it just uses get_base_element_type instead of get_element_type

Re: [HACKERS] PL/Python: domain over array support

On Sat, Oct 26, 2013 at 11:17:19AM -0200, Rodolfo Campero wrote: > The attached patch add support of domains over arrays to PL/Python (eg: > CREATE DOMAIN my_domain AS integer[]). > > Basically it just uses get_base_element_type instead of get_element_type > in plpy_typeio.c, and uses domain_check

Re: [HACKERS] PL/Python: domain over array support

Done, thanks. 2013/10/28 Robert Haas > On Sat, Oct 26, 2013 at 9:17 AM, Rodolfo Campero > wrote: > > The attached patch add support of domains over arrays to PL/Python (eg: > > CREATE DOMAIN my_domain AS integer[]). > > > > Basically it just uses get_base_element_type instead of get_element_ty

Re: [HACKERS] PL/Python: domain over array support

On Sat, Oct 26, 2013 at 9:17 AM, Rodolfo Campero wrote: > The attached patch add support of domains over arrays to PL/Python (eg: > CREATE DOMAIN my_domain AS integer[]). > > Basically it just uses get_base_element_type instead of get_element_type in > plpy_typeio.c, and uses domain_check before r

[HACKERS] PL/Python: domain over array support

The attached patch add support of domains over arrays to PL/Python (eg: CREATE DOMAIN my_domain AS integer[]). Basically it just uses get_base_element_type instead of get_element_type in plpy_typeio.c, and uses domain_check before returning a sequence as array in PLySequence_ToArray whenever appro

Re: [HACKERS] PL/Python result object str handler

On Sat, 2013-02-02 at 15:43 -0500, Steve Singer wrote: > I've looked through the code and everything looks fine. > > The patch includes no documentation. Adding a few lines to the > "Utility Functions" section of the plpython documentation so people know > about this feature would be good. Ad

Re: [HACKERS] PL/Python result object str handler

On 13-01-07 09:58 PM, Peter Eisentraut wrote: By implementing a "str" handler for the result object, it now prints something like Patch attached for review. Here is a review: This patch adds a function that pl/python functions can call to convert a query result hash into a string suitable

Re: [HACKERS] PL/Python result object str handler

On 1/8/13 11:55 AM, Daniele Varrazzo wrote: >>> >> 'bar': '22'}]> > This looks more a repr-style format to me (if you implement repr but > not str, the latter will default to the former). The repr style was the only guideline I found. There is no guideline for how str should look like when it's n

Re: [HACKERS] PL/Python result object str handler

On Tue, Jan 8, 2013 at 10:23 PM, Peter Eisentraut wrote: > On 1/8/13 4:32 AM, Magnus Hagander wrote: >> How does it work if there are many rows in there? Say the result >> contains 10,000 rows - will the string contain all of them? If so, >> might it be worthwhile to cap the number of rows shown a

Re: [HACKERS] PL/Python result object str handler

On 1/8/13 4:32 AM, Magnus Hagander wrote: > How does it work if there are many rows in there? Say the result > contains 10,000 rows - will the string contain all of them? If so, > might it be worthwhile to cap the number of rows shown and then follow > with a "..." or something? I don't think so.

Re: [HACKERS] PL/Python result object str handler

On Tue, Jan 8, 2013 at 9:32 AM, Magnus Hagander wrote: > On Tue, Jan 8, 2013 at 3:58 AM, Peter Eisentraut wrote: >> For debugging PL/Python functions, I'm often tempted to write something >> like >> >> rv = plpy.execute(...) >> plpy.info(rv) >> >> which prints something unhelpful like >> >> >> >

Re: [HACKERS] PL/Python result object str handler

On Tue, Jan 8, 2013 at 3:58 AM, Peter Eisentraut wrote: > For debugging PL/Python functions, I'm often tempted to write something > like > > rv = plpy.execute(...) > plpy.info(rv) > > which prints something unhelpful like > > > > By implementing a "str" handler for the result object, it now print

[HACKERS] PL/Python result object str handler

For debugging PL/Python functions, I'm often tempted to write something like rv = plpy.execute(...) plpy.info(rv) which prints something unhelpful like By implementing a "str" handler for the result object, it now prints something like Patch attached for review. diff --git a/src/pl/plpytho

Re: [HACKERS] pl/python custom datatype parsers

Did any (committed?) code result from this thread ? On 11/10/2011 09:13 PM, Peter Eisentraut wrote: On tis, 2011-11-08 at 16:08 -0500, Andrew Dunstan wrote: On 03/01/2011 11:50 AM, Peter Eisentraut wrote: On fre, 2011-02-11 at 16:49 +0100, Jan Urbański wrote: I believe it's (b). But as we do

Re: [HACKERS] PL/Python result set slicing broken in Python 3

On fre, 2012-05-11 at 11:28 +0200, Jan Urbański wrote: > On 10/05/12 19:45, Peter Eisentraut wrote: > > On lör, 2012-05-05 at 22:45 +0200, Jan Urbański wrote: > >> Apparently once you implement PyMappingMethods.mp_subscript you can > >> drop PySequenceMethods.sq_slice, but I guess there's no harm i

Re: [HACKERS] PL/Python result set slicing broken in Python 3

On 10/05/12 19:45, Peter Eisentraut wrote: On lör, 2012-05-05 at 22:45 +0200, Jan Urbański wrote: Apparently once you implement PyMappingMethods.mp_subscript you can drop PySequenceMethods.sq_slice, but I guess there's no harm in keeping it (and I'm not sure it'd work on Python 2.3 with only mp_

Re: [HACKERS] PL/Python result set slicing broken in Python 3

On lör, 2012-05-05 at 22:45 +0200, Jan Urbański wrote: > Apparently once you implement PyMappingMethods.mp_subscript you can > drop PySequenceMethods.sq_slice, but I guess there's no harm in > keeping it (and I'm not sure it'd work on Python 2.3 with only > mp_subscript implemented). Committed thi

Re: [HACKERS] PL/Python result set slicing broken in Python 3

On tor, 2012-05-10 at 12:37 -0400, Robert Haas wrote: > On Sat, May 5, 2012 at 4:45 PM, Jan Urbański wrote: > >> I found some instructions on how to deal with the Python 2/Python 3 > >> slicing mess: > >> > >> > >> http://renesd.blogspot.com/2009/07/python3-c-api-simple-slicing-sqslice.html > > >

Re: [HACKERS] PL/Python result set slicing broken in Python 3

On Sat, May 5, 2012 at 4:45 PM, Jan Urbański wrote: >> I found some instructions on how to deal with the Python 2/Python 3 >> slicing mess: >> >> >> http://renesd.blogspot.com/2009/07/python3-c-api-simple-slicing-sqslice.html > > > Thanks to the helpful folk at #python I found out that the fix is

Re: [HACKERS] PL/Python result set slicing broken in Python 3

On 04/05/12 20:00, Jan Urbański wrote: On 03/05/12 11:04, Jan Urbański wrote: On 02/05/12 20:18, Peter Eisentraut wrote: This doesn't work anymore with Python 3: rv = plpy.execute(...) do_something(rv[0:1]) Sounds ugly. I'll take a look. I found some instructions on how to deal with the Py

Re: [HACKERS] PL/Python result set slicing broken in Python 3

On 03/05/12 11:04, Jan Urbański wrote: On 02/05/12 20:18, Peter Eisentraut wrote: This doesn't work anymore with Python 3: rv = plpy.execute(...) do_something(rv[0:1]) Apparently, they changed the C API for doing slicing, or rather made one of the two APIs for it silently do nothing. Details a

Re: [HACKERS] PL/Python result set slicing broken in Python 3

On 02/05/12 20:18, Peter Eisentraut wrote: This doesn't work anymore with Python 3: rv = plpy.execute(...) do_something(rv[0:1]) Apparently, they changed the C API for doing slicing, or rather made one of the two APIs for it silently do nothing. Details are difficult to find, but this email me

[HACKERS] PL/Python result set slicing broken in Python 3

This doesn't work anymore with Python 3: rv = plpy.execute(...) do_something(rv[0:1]) Apparently, they changed the C API for doing slicing, or rather made one of the two APIs for it silently do nothing. Details are difficult to find, but this email message seems to contain something:

Re: [HACKERS] pl/python long-lived allocations in datum->dict transformation

=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes: > I came up with a stack of context structures that gets pushed when a > PL/Python starts being executed and popped when it returns. At first > they contained just a scratch memory context used by PLyDict_FromTuple. > Then under the premise of confirming th

Re: [HACKERS] pl/python long-lived allocations in datum->dict transformation

On 14/02/12 01:35, Tom Lane wrote: > =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes: >> It's not very comfortable, but >> I think PLyDict_FromTuple can be allowed to be non-reentrant. > > I think that's pretty short-sighted. Even if it's safe today (which > I am not 100% convinced of), there are plenty

Re: [HACKERS] pl/python long-lived allocations in datum->dict transformation

=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes: > On 12/02/12 00:48, Tom Lane wrote: >> What's more, it's unclear that >> it won't malfunction altogether if the function is used recursively >> (ie, what if PLyDict_FromTuple ends up calling the same function again?) > I was a bit worried about that, but

Re: [HACKERS] pl/python long-lived allocations in datum->dict transformation

On 12/02/12 00:48, Tom Lane wrote: > =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes: >> This is annoying for functions that plough through large tables, doing >> some calculation. Attached is a patch that does the conversion of >> PostgreSQL Datums into Python dict objects in a scratch memory context >>

Re: [HACKERS] pl/python long-lived allocations in datum->dict transformation

=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes: > This is annoying for functions that plough through large tables, doing > some calculation. Attached is a patch that does the conversion of > PostgreSQL Datums into Python dict objects in a scratch memory context > that gets reset every time. As best I ca

[HACKERS] pl/python long-lived allocations in datum->dict transformation

Consider this: create table arrays as select array[random(), random(), random(), random(), random(), random()] as a from generate_series(1, 100); create or replace function plpython_outputfunc() returns void as $$ c = plpy.cursor('select a from arrays') for row in c: pass $$ language plpy

Re: [HACKERS] PL/Python result metadata

At 2012-01-11 22:05:34 +0200, pete...@gmx.net wrote: > > I propose to add two functions to the result object: > > .colnames() returns a list of column names (strings) > .coltypes() returns a list of type OIDs (integers) […] > > Patch attached. Comments welcome. Applies, builds, passes tests. Co

Re: [HACKERS] PL/Python result metadata

Peter Eisentraut writes: > I deliberately chose not to do that, because the PL/Python API is > intentionally totally different from the standard DB-API, and mixing in > some semi-conforming look-alike would be quite confusing from both ends. Fair enough. > I think we should stick with the PL/Pyt

Re: [HACKERS] PL/Python result metadata

On ons, 2012-01-11 at 22:52 +0100, Dimitri Fontaine wrote: > Peter Eisentraut writes: > > .colnames() returns a list of column names (strings) > > .coltypes() returns a list of type OIDs (integers) > > > > I just made that up because there is no guidance in the other standard > > PLs for this sort

Re: [HACKERS] PL/Python result metadata

On ons, 2012-01-11 at 17:16 -0300, Alvaro Herrera wrote: > > I propose to add two functions to the result object: > > > > .colnames() returns a list of column names (strings) > > .coltypes() returns a list of type OIDs (integers) > > No typmods? Didn't think about that, but could be added using

Re: [HACKERS] PL/Python result metadata

On 11/01/12 22:52, Dimitri Fontaine wrote: > Peter Eisentraut writes: >> .colnames() returns a list of column names (strings) >> .coltypes() returns a list of type OIDs (integers) >> >> I just made that up because there is no guidance in the other standard >> PLs for this sort of thing, AFAICT. >

Re: [HACKERS] PL/Python result metadata

Peter Eisentraut writes: > .colnames() returns a list of column names (strings) > .coltypes() returns a list of type OIDs (integers) > > I just made that up because there is no guidance in the other standard > PLs for this sort of thing, AFAICT. What about having the same or comparable API as in

Re: [HACKERS] PL/Python result metadata

Excerpts from Peter Eisentraut's message of mié ene 11 17:05:34 -0300 2012: > There is currently no reliable way to retrieve from a result object in > PL/Python the number, name, or type of the result columns. You can get > the number and name if the query returned more than zero rows by looking

[HACKERS] PL/Python result metadata

There is currently no reliable way to retrieve from a result object in PL/Python the number, name, or type of the result columns. You can get the number and name if the query returned more than zero rows by looking at the row dicts, but that is unreliable. The type information isn't available at

Re: [HACKERS] PL/Python SQL error code pass-through

On 24.11.2011 23:56, Jan Urbański wrote: On 24/11/11 16:15, Heikki Linnakangas wrote: On 24.11.2011 10:07, Jan Urbański wrote: On 23/11/11 17:24, Mika Eloranta wrote: [PL/Python in 9.1 does not preserve SQLSTATE of errors] Oops, you're right, it's a regression from 9.0 behaviour. The fix lo

Re: [HACKERS] PL/Python SQL error code pass-through

On 24/11/11 16:15, Heikki Linnakangas wrote: On 24.11.2011 10:07, Jan Urbański wrote: On 23/11/11 17:24, Mika Eloranta wrote: Hi all, [PL/Python in 9.1 does not preserve SQLSTATE of errors] Oops, you're right, it's a regression from 9.0 behaviour. The fix looks good to me, I changed one pla

Re: [HACKERS] PL/Python SQL error code pass-through

On 24.11.2011 10:07, Jan Urbański wrote: On 23/11/11 17:24, Mika Eloranta wrote: Hi all, [PL/Python in 9.1 does not preserve SQLSTATE of errors] Oops, you're right, it's a regression from 9.0 behaviour. The fix looks good to me, I changed one place to indent with tabs instead of spaces and a

Re: [HACKERS] PL/Python SQL error code pass-through

On 23/11/11 17:24, Mika Eloranta wrote: Hi all, [PL/Python in 9.1 does not preserve SQLSTATE of errors] Oops, you're right, it's a regression from 9.0 behaviour. The fix looks good to me, I changed one place to indent with tabs instead of spaces and added a regression test. I think this sh

[HACKERS] PL/Python SQL error code pass-through

Hi all, Here's a little SQL snippet that exposes an apparent regression in the 9.1.x PL/Python behavior: ---clip--- # cat foo.sql \set VERBOSITY 'verbose' CREATE table bar (a INTEGER CONSTRAINT hello CHECK (a > 1)); CREATE OR REPLACE FUNCTION foo () RETURNS integer AS $$ plpy.execute("INS

Re: [HACKERS] pl/python custom datatype parsers

On tis, 2011-11-08 at 16:08 -0500, Andrew Dunstan wrote: > > On 03/01/2011 11:50 AM, Peter Eisentraut wrote: > > On fre, 2011-02-11 at 16:49 +0100, Jan Urbański wrote: > >> I believe it's (b). But as we don't have time for that discussion that > >> late in the release cycle, I think we need to con

Re: [HACKERS] pl/python custom datatype parsers

On 03/01/2011 11:50 AM, Peter Eisentraut wrote: On fre, 2011-02-11 at 16:49 +0100, Jan Urbański wrote: I believe it's (b). But as we don't have time for that discussion that late in the release cycle, I think we need to consider it identical to (c). As I previously mentioned, I think that the

Re: [HACKERS] PL/Python: No stack trace for an exception

On Thu, 2011-07-21 at 15:31 +0200, Jan Urbański wrote: > On 21/07/11 15:27, Sushant Sinha wrote: > > I am using plpythonu on postgres 9.0.2. One of my python functions was > > throwing a TypeError exception. However, I only see the exception in the > > database and not the stack trace. It becomes

Re: [HACKERS] PL/Python: No stack trace for an exception

On 21/07/11 15:27, Sushant Sinha wrote: > I am using plpythonu on postgres 9.0.2. One of my python functions was > throwing a TypeError exception. However, I only see the exception in the > database and not the stack trace. It becomes difficult to debug if the > stack trace is absent in Python. >

Re: [HACKERS] PL/Python: No stack trace for an exception

On 21 July 2011 14:27, Sushant Sinha wrote: > I am using plpythonu on postgres 9.0.2. One of my python functions was > throwing a TypeError exception. However, I only see the exception in the > database and not the stack trace. It becomes difficult to debug if the > stack trace is absent in Python

[HACKERS] PL/Python: No stack trace for an exception

I am using plpythonu on postgres 9.0.2. One of my python functions was throwing a TypeError exception. However, I only see the exception in the database and not the stack trace. It becomes difficult to debug if the stack trace is absent in Python. logdb=# select get_words(forminput) from fi;

Re: [HACKERS] pl/python tracebacks v2

On Wed, 2011-04-06 at 23:54 +0200, Jan Urbański wrote: > > Ouch, just today I found a flaw in this, namely that it assumes the > > lineno from the traceback always refers to the PL/Python function. If > > you create a PL/Python function that imports some code, runs it, and > > that code raises an e

Re: [HACKERS] pl/python tracebacks v2

On 06/04/11 22:16, Jan Urbański wrote: > On 06/04/11 21:38, Peter Eisentraut wrote: >> On mån, 2011-03-21 at 00:40 +0100, Jan Urbański wrote: >>> I finally got around to updating the PL/Python tracebacks patch. The >>> other day I was writing some very simple PL/Python code and the lack of >>> trac

Re: [HACKERS] pl/python tracebacks v2

On 06/04/11 21:38, Peter Eisentraut wrote: > On mån, 2011-03-21 at 00:40 +0100, Jan Urbański wrote: >> I finally got around to updating the PL/Python tracebacks patch. The >> other day I was writing some very simple PL/Python code and the lack of >> tracebacks is extremely annoying. > > I tweaked

Re: [HACKERS] pl/python tracebacks v2

On mån, 2011-03-21 at 00:40 +0100, Jan Urbański wrote: > I finally got around to updating the PL/Python tracebacks patch. The > other day I was writing some very simple PL/Python code and the lack of > tracebacks is extremely annoying. I tweaked this a bit to make the patch less invasive, and then

Re: [HACKERS] pl/python tracebacks v2

On 20 March 2011 23:40, Jan Urbański wrote: > I'll update the commitfest app for the 2011-Next commitfest, but if > someone would like to pick this up and include it in the 9.1 PL/Python > revamp pack, I'd be thrilled. I would also be thrilled. I definitely share your sense of frustration about t

[HACKERS] pl/python - thanks!

Hi, I just wanted to thank everyone involved in shepherding the PL/Python patches into the master repo, the testers, reviewers, commenters and especially Peter, for their help and diligence. The outstanding tracebacks patch is still being worked on, but irrelevant of whether it will make it or no

  1   2   3   4   >