2010/11/18 Pavel Stehule <pavel.stehule@gmail.com>:
> 2010/11/18 Tom Lane <tgl@sss.pgh.pa.us>:
>> Merlin Moncure <mmoncure@gmail.com> writes:
>>> On Wed, Nov 17, 2010 at 7:08 PM, Jaime Casanova <jaime@2ndquadrant.com> wrote:
>>>> i will start the review of this one... but before that sorry for
>>>> suggesting this a bit later but about using UNNEST as part of the
>>>> sintax?
>>
>>> Does for-in-array do what unnset does?
>>
>> Yes, which begs the question of why bother at all. AFAICS this patch
>> simply allows you to replace
>>
>> for x in select unnest(array_value) loop
>>
>> with
>>
>> for x in unnest array_value loop
>>
>> (plus or minus a parenthesis or so). I do not think we need to add a
>> bunch of code and create even more syntactic ambiguity (FOR loops are
>> already on the hairy edge of unparsability) to save people from writing
>> "select".
>
> this patch is semantically equal to SELECT unnest(..), but it is
> evaluated as simple expression and does directly array unpacking and
> iteration, - so it means this fragment is significantly >>faster<<.
Did you implement a method to be able to walk the array and detoast
only the current needed data ?
(I wonder because I have something like that in that garage : select
array_filter(foo,'like','%bar%',10); where 10 is the limit and can be
avoided, foo is the array, like is callback function, '%bar%' the
parameter for the callback function for filtering results.)
It will make my toy in the garage a fast race car (and probably doable
in (plpg)SQL instead of C) ...
--
Cédric Villemain 2ndQuadrant
http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support
