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

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

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

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

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

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

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

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

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

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

Re: [HACKERS] pl/python tracebacks

On 07/03/11 22:55, Peter Eisentraut wrote: > On mån, 2011-03-07 at 14:19 +0100, Jan Urbański wrote: >> On 07/03/11 14:01, Jan Urbański wrote: >>> On 07/03/11 13:53, Peter Eisentraut wrote: On sön, 2011-03-06 at 13:14 +0100, Jan Urbański wrote: > But fixing "raise plpy.Fatal()" > to act

Re: [HACKERS] pl/python tracebacks

On mån, 2011-03-07 at 14:19 +0100, Jan Urbański wrote: > On 07/03/11 14:01, Jan Urbański wrote: > > On 07/03/11 13:53, Peter Eisentraut wrote: > >> On sön, 2011-03-06 at 13:14 +0100, Jan Urbański wrote: > >>> But fixing "raise plpy.Fatal()" > >>> to actually cause a FATAL is something that should b

Re: [HACKERS] pl/python tracebacks

On 07/03/11 14:01, Jan Urbański wrote: > On 07/03/11 13:53, Peter Eisentraut wrote: >> On sön, 2011-03-06 at 13:14 +0100, Jan Urbański wrote: >>> But fixing "raise plpy.Fatal()" >>> to actually cause a FATAL is something that should be extracted from >>> this patch and committed, even if the full p

Re: [HACKERS] pl/python tracebacks

On 07/03/11 13:53, Peter Eisentraut wrote: > On sön, 2011-03-06 at 13:14 +0100, Jan Urbański wrote: >> But fixing "raise plpy.Fatal()" >> to actually cause a FATAL is something that should be extracted from >> this patch and committed, even if the full patch does not make it. > > Um, what? I didn

Re: [HACKERS] pl/python tracebacks

On 07/03/11 13:53, Peter Eisentraut wrote: > On ons, 2011-03-02 at 22:28 +0100, Jan Urbański wrote: >> I did some tests with the attached test script, calling various of the >> functions defined there and the error messages more or less made sense >> (or at least were not worse than before). > > I

Re: [HACKERS] pl/python tracebacks

On sön, 2011-03-06 at 13:14 +0100, Jan Urbański wrote: > But fixing "raise plpy.Fatal()" > to actually cause a FATAL is something that should be extracted from > this patch and committed, even if the full patch does not make it. Um, what? I didn't find any details about this in this thread, nor a

Re: [HACKERS] pl/python tracebacks

On ons, 2011-03-02 at 22:28 +0100, Jan Urbański wrote: > I did some tests with the attached test script, calling various of the > functions defined there and the error messages more or less made sense > (or at least were not worse than before). Is that script part of the regression tests you added

Re: [HACKERS] pl/python tracebacks

On 02/03/11 22:28, Jan Urbański wrote: > On 01/03/11 22:12, Peter Eisentraut wrote: >> On tis, 2011-03-01 at 21:10 +0100, Jan Urbański wrote: >>> So you end up with a context message saying "PL/Python function %s" >>> and a detail message with the saved detail (if it's present) *and* the >>> traceb

Re: [HACKERS] pl/python tracebacks

On tis, 2011-03-01 at 21:10 +0100, Jan Urbański wrote: > So you end up with a context message saying "PL/Python function %s" > and a detail message with the saved detail (if it's present) *and* the > traceback. The problem is that the name of the function is already in > the traceback, so there's n

Re: [HACKERS] pl/python tracebacks

On Mar 1, 2011, at 12:10 PM, Jan Urbański wrote: > So you end up with a context message saying "PL/Python function %s" and > a detail message with the saved detail (if it's present) *and* the > traceback. The problem is that the name of the function is already in > the traceback, so there's no need

  1   2   3   >