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
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
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
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,
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
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
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
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,
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
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
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
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
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,
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
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
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
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
>
> 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
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
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=#
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
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
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
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
>
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
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
26 matches
Mail list logo
