In previous versions (8.x) for plpython fn returning integer[]
I created (had to create) a string in the proper SQL format {
{1,2,3}, {4,5,6} }
and returned that. It worked fine.
I LIKE the ability to not have to do that in 9.0
but I CAN'T return and string like { {1,2,3}, {4,5,6} } for a fn th
On Tuesday 21 December 2010 3:25:48 pm Peter Geoghegan wrote:
> On 21 December 2010 23:17, Thom Brown wrote:
> > Are you sure that "a" returns okay in that scenario. You're using a
> > list. Shouldn't you be using an array? Like: a = []
>
> a =[] actually declares an empty list in Python. You c
On Tuesday 21 December 2010 2:48:16 pm TJ O'Donnell wrote:
> In postgresql-9.0.1 I have to modify my plpython functions that return
> arrays. It seems one dimesional arrays are handled properly, but not
> 2-dimensional arrays.
>
> create or replace function atest() returns integer[] as $eopy$
> a
On 21 December 2010 23:17, Thom Brown wrote:
> Are you sure that "a" returns okay in that scenario. You're using a
> list. Shouldn't you be using an array? Like: a = []
a =[] actually declares an empty list in Python. You can return a list
or a tuple from a pl/python function in 9.0 and it wil
On 21 December 2010 22:48, TJ O'Donnell wrote:
> In postgresql-9.0.1 I have to modify my plpython functions that return arrays.
> It seems one dimesional arrays are handled properly, but not
> 2-dimensional arrays.
>
> create or replace function atest() returns integer[] as $eopy$
> a = list()
>
In postgresql-9.0.1 I have to modify my plpython functions that return arrays.
It seems one dimesional arrays are handled properly, but not
2-dimensional arrays.
create or replace function atest() returns integer[] as $eopy$
a = list()
a.append(1)
a.append(2)
a.append(3)
#return a works fine