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