Re: proposal: searching in array function - array_position

On 2/22/15 5:19 AM, Pavel Stehule wrote:

2015-02-22 3:00 GMT+01:00 Petr Jelinek <petr@2ndquadrant.com
<mailto:petr@2ndquadrant.com>>:

    On 28/01/15 08:15, Pavel Stehule wrote:



        2015-01-28 0:01 GMT+01:00 Jim Nasby <Jim.Nasby@bluetreble.com
        <mailto:Jim.Nasby@bluetreble.com>
        <mailto:Jim.Nasby@bluetreble.__com
        <mailto:Jim.Nasby@bluetreble.com>>>:

             On 1/27/15 4:36 AM, Pavel Stehule wrote:


                 It is only partially identical - I would to use cache for
                 array_offset, but it is not necessary for array_offsets ..
                 depends how we would to modify current API to support
        externally
                 cached data.


             Externally cached data?


        Some from these functions has own caches for minimize access to
        typcache
        (array_map, array_cmp is example). And in first case, I am trying to
        push these information from fn_extra, in second case I don't do it,
        because I don't expect a repeated call (and I am expecting so
        type cache
        will be enough).


    You actually do caching via fn_extra in both case and I think that's
    the correct way, and yes that part can be moved common function.

    I also see that the documentation does not say what is returned by
    array_offset if nothing is found (it's documented in code but not in
    sgml).


rebased + fixed docs

I don't think we need both array_offset and array_offset_start; can't both SQL functions just call one C function?

It might be worth combining the array and non-array versions of this, by having a _common function that accepts a boolean and then just run one or the other of the while loops. Most of the code seems to be shared between the two versions.

What is this comment supposed to mean? There is no 'width_array'...

 * Biggest difference against width_array is unsorted input array.

I've attached my doc changes, both alone and with the code.

--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com