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
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.
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
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
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
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;
$$
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,
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
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
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
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
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,
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,
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
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
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 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
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
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:
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 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 <
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
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
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
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