proposal: searching in array function - array_position
Hi
I am proposing a simple function, that returns a position of element in
array.
FUNCTION array_position(anyarray, anyelement) RETURNS int
Implementation is simple (plpgsql code)
CREATE OR REPLACE FUNCTION array_position(anyarray, anyelement)
RETURNS int AS $$
DECLARE i int := 0;
BEGIN
FOREACH a IN ARRAY $1
LOOP
IF a = $1 THEN
RETURN i;
END IF;
i := i + 1;
END LOOP;
RETURN NULL;
END;
$$ LANGUAGE plpgsql IMMUTABLE STRICT;
A possible benefits:
1. speed in plpgsql applications
2. reduced length of SQL functions
Ideas, comments, notices?
Regards
Pavel
On 1/16/15 3:39 AM, Pavel Stehule wrote:
I am proposing a simple function, that returns a position of element in array.
Yes please!
FUNCTION array_position(anyarray, anyelement) RETURNS int
That won't work on a multi-dimensional array. Ideally it needs to accept a slice or an element and return the specifier for the slice.
This wouldn't be so bad if we had an easier way to extract subsets of an array, but even that is really ugly because whatever you extract keeps the original number of dimensions.
Implementation is simple (plpgsql code)
This would actually be written in C though, yes? Otherwise it's not really any better than just doing an extension...
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2015-01-16 17:57 GMT+01:00 Jim Nasby <Jim.Nasby@bluetreble.com>:
On 1/16/15 3:39 AM, Pavel Stehule wrote:
I am proposing a simple function, that returns a position of element in
array.Yes please!
FUNCTION array_position(anyarray, anyelement) RETURNS int
That won't work on a multi-dimensional array. Ideally it needs to accept a
slice or an element and return the specifier for the slice.
It is question, what is a result - probably, there can be a
multidimensional variant, where result will be a array
array_position([1,2,3],2) --> 2
array_position([[1,2],[2,3],[3,4]], [2,3]) --> 2 /* 2nd parameter should to
have N-1 dimension of first parameter */
array_position_md([1,2,3],2) --> [2]
array_position_md([[1,2],[2,3],[3,4]], 2) --> [2,1]
another question is how to solve more than one occurrence on one value -
probably two sets of functions - first returns first occurrence of value,
second returns set of occurrence
This wouldn't be so bad if we had an easier way to extract subsets of an
array, but even that is really ugly because whatever you extract keeps the
original number of dimensions.Implementation is simple (plpgsql code)
This would actually be written in C though, yes? Otherwise it's not really
any better than just doing an extension...
Sure, I expect a C implementation
Pavel
Show quoted text
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
On 1/16/15 11:16 AM, Pavel Stehule wrote:
2015-01-16 17:57 GMT+01:00 Jim Nasby <Jim.Nasby@bluetreble.com <mailto:Jim.Nasby@bluetreble.com>>:
On 1/16/15 3:39 AM, Pavel Stehule wrote:
I am proposing a simple function, that returns a position of element in array.
Yes please!
FUNCTION array_position(anyarray, anyelement) RETURNS int
That won't work on a multi-dimensional array. Ideally it needs to accept a slice or an element and return the specifier for the slice.
It is question, what is a result - probably, there can be a multidimensional variant, where result will be a array
array_position([1,2,3],2) --> 2
array_position([[1,2],[2,3],[3,4]], [2,3]) --> 2 /* 2nd parameter should to have N-1 dimension of first parameter */
The problem with that is you can't actually use '2' to get [2,3] back:
select (array[[1,2,3],[4,5,6],[7,8,9]])[1] IS NULL;
?column?
----------
t
(1 row)
I think the bigger problem here is we need something better than slices for handling subsets of arrays. Even if the function returned [2:2] it's still going to behave differently than it will in the non-array case because you won't be getting the expected number of dimensions back. :(
array_position_md([1,2,3],2) --> [2]
array_position_md([[1,2],[2,3],[3,4]], 2) --> [2,1]another question is how to solve more than one occurrence on one value - probably two sets of functions - first returns first occurrence of value, second returns set of occurrence
Gee, if only way had some way to return multiple elements of something... ;P
In other words, I think all of these should actually return an array of positions. I think it's OK for someone that only cares about the first instance to just do [1].
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2015-01-16 18:37 GMT+01:00 Jim Nasby <Jim.Nasby@bluetreble.com>:
On 1/16/15 11:16 AM, Pavel Stehule wrote:
2015-01-16 17:57 GMT+01:00 Jim Nasby <Jim.Nasby@bluetreble.com <mailto:
Jim.Nasby@bluetreble.com>>:On 1/16/15 3:39 AM, Pavel Stehule wrote:
I am proposing a simple function, that returns a position of
element in array.Yes please!
FUNCTION array_position(anyarray, anyelement) RETURNS int
That won't work on a multi-dimensional array. Ideally it needs to
accept a slice or an element and return the specifier for the slice.It is question, what is a result - probably, there can be a
multidimensional variant, where result will be a arrayarray_position([1,2,3],2) --> 2
array_position([[1,2],[2,3],[3,4]], [2,3]) --> 2 /* 2nd parameter should
to have N-1 dimension of first parameter */The problem with that is you can't actually use '2' to get [2,3] back:
select (array[[1,2,3],[4,5,6],[7,8,9]])[1] IS NULL;
?column?
----------
t
(1 row)
yes, but when you are searching a array in array you can use a full slice
selection:
postgres=# select (ARRAY[[1,2],[4,5]])[1][1:2]; -- [1:2] should be a
constant every time in this case -- so it should not be returned
array
---------
{{1,2}}
(1 row)
I think the bigger problem here is we need something better than slices
for handling subsets of arrays. Even if the function returned [2:2] it's
still going to behave differently than it will in the non-array case
because you won't be getting the expected number of dimensions back. :(
you cannot to return a slice and I don't propose it, although we can return
a range type or array of range type - but still we cannot to use range for
a arrays.
array_position_md([1,2,3],2) --> [2]
array_position_md([[1,2],[2,3],[3,4]], 2) --> [2,1]
another question is how to solve more than one occurrence on one value -
probably two sets of functions - first returns first occurrence of value,
second returns set of occurrenceGee, if only way had some way to return multiple elements of something...
;PIn other words, I think all of these should actually return an array of
positions. I think it's OK for someone that only cares about the first
instance to just do [1].
there can be two functions - "position" - returns first and "positions"
returns all as a array
Show quoted text
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
2015-01-16 17:57 GMT+01:00 Jim Nasby <Jim.Nasby@bluetreble.com>:
On 1/16/15 3:39 AM, Pavel Stehule wrote:
I am proposing a simple function, that returns a position of element in
array.Yes please!
FUNCTION array_position(anyarray, anyelement) RETURNS int
That won't work on a multi-dimensional array. Ideally it needs to accept a
slice or an element and return the specifier for the slice.
theoretically you can use this function for md arrays too. This function
returns offset, and you can calculate a Nd possition
so maybe better name -- array_offset or some similar
Regards
Pavel
Show quoted text
This wouldn't be so bad if we had an easier way to extract subsets of an
array, but even that is really ugly because whatever you extract keeps the
original number of dimensions.Implementation is simple (plpgsql code)
This would actually be written in C though, yes? Otherwise it's not really
any better than just doing an extension...
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
Hi
here is a proof concept of array_offset function
possible question:
* used comparation "=" or "IS NOT DISTINCT FROM"
In this initial proof concept I used "IS NOT DISTINCT FROM" operator - but
my opinion is not strong in this question. Both has some advantages and
disadvantages.
Regards
Pavel
2015-01-16 19:12 GMT+01:00 Pavel Stehule <pavel.stehule@gmail.com>:
Show quoted text
2015-01-16 18:37 GMT+01:00 Jim Nasby <Jim.Nasby@bluetreble.com>:
On 1/16/15 11:16 AM, Pavel Stehule wrote:
2015-01-16 17:57 GMT+01:00 Jim Nasby <Jim.Nasby@bluetreble.com <mailto:
Jim.Nasby@bluetreble.com>>:On 1/16/15 3:39 AM, Pavel Stehule wrote:
I am proposing a simple function, that returns a position of
element in array.Yes please!
FUNCTION array_position(anyarray, anyelement) RETURNS int
That won't work on a multi-dimensional array. Ideally it needs to
accept a slice or an element and return the specifier for the slice.It is question, what is a result - probably, there can be a
multidimensional variant, where result will be a arrayarray_position([1,2,3],2) --> 2
array_position([[1,2],[2,3],[3,4]], [2,3]) --> 2 /* 2nd parameter
should to have N-1 dimension of first parameter */The problem with that is you can't actually use '2' to get [2,3] back:
select (array[[1,2,3],[4,5,6],[7,8,9]])[1] IS NULL;
?column?
----------
t
(1 row)yes, but when you are searching a array in array you can use a full slice
selection:postgres=# select (ARRAY[[1,2],[4,5]])[1][1:2]; -- [1:2] should be a
constant every time in this case -- so it should not be returned
array
---------
{{1,2}}
(1 row)I think the bigger problem here is we need something better than slices
for handling subsets of arrays. Even if the function returned [2:2] it's
still going to behave differently than it will in the non-array case
because you won't be getting the expected number of dimensions back. :(you cannot to return a slice and I don't propose it, although we can
return a range type or array of range type - but still we cannot to use
range for a arrays.array_position_md([1,2,3],2) --> [2]
array_position_md([[1,2],[2,3],[3,4]], 2) --> [2,1]
another question is how to solve more than one occurrence on one value -
probably two sets of functions - first returns first occurrence of value,
second returns set of occurrenceGee, if only way had some way to return multiple elements of something...
;PIn other words, I think all of these should actually return an array of
positions. I think it's OK for someone that only cares about the first
instance to just do [1].there can be two functions - "position" - returns first and "positions"
returns all as a array--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
Attachments:
array_offset-01.patchtext/x-patch; charset=US-ASCII; name=array_offset-01.patchDownload+222-7
Hi
I am sending updated version - it allow third optional argument that
specify where searching should to start. With it is possible repeatably
call this function.
Regards
Pavel
2015-01-17 23:43 GMT+01:00 Pavel Stehule <pavel.stehule@gmail.com>:
Show quoted text
Hi
here is a proof concept of array_offset function
possible question:
* used comparation "=" or "IS NOT DISTINCT FROM"
In this initial proof concept I used "IS NOT DISTINCT FROM" operator - but
my opinion is not strong in this question. Both has some advantages and
disadvantages.Regards
Pavel
2015-01-16 19:12 GMT+01:00 Pavel Stehule <pavel.stehule@gmail.com>:
2015-01-16 18:37 GMT+01:00 Jim Nasby <Jim.Nasby@bluetreble.com>:
On 1/16/15 11:16 AM, Pavel Stehule wrote:
2015-01-16 17:57 GMT+01:00 Jim Nasby <Jim.Nasby@bluetreble.com <mailto:
Jim.Nasby@bluetreble.com>>:On 1/16/15 3:39 AM, Pavel Stehule wrote:
I am proposing a simple function, that returns a position of
element in array.Yes please!
FUNCTION array_position(anyarray, anyelement) RETURNS int
That won't work on a multi-dimensional array. Ideally it needs to
accept a slice or an element and return the specifier for the slice.It is question, what is a result - probably, there can be a
multidimensional variant, where result will be a arrayarray_position([1,2,3],2) --> 2
array_position([[1,2],[2,3],[3,4]], [2,3]) --> 2 /* 2nd parameter
should to have N-1 dimension of first parameter */The problem with that is you can't actually use '2' to get [2,3] back:
select (array[[1,2,3],[4,5,6],[7,8,9]])[1] IS NULL;
?column?
----------
t
(1 row)yes, but when you are searching a array in array you can use a full slice
selection:postgres=# select (ARRAY[[1,2],[4,5]])[1][1:2]; -- [1:2] should be a
constant every time in this case -- so it should not be returned
array
---------
{{1,2}}
(1 row)I think the bigger problem here is we need something better than slices
for handling subsets of arrays. Even if the function returned [2:2] it's
still going to behave differently than it will in the non-array case
because you won't be getting the expected number of dimensions back. :(you cannot to return a slice and I don't propose it, although we can
return a range type or array of range type - but still we cannot to use
range for a arrays.array_position_md([1,2,3],2) --> [2]
array_position_md([[1,2],[2,3],[3,4]], 2) --> [2,1]
another question is how to solve more than one occurrence on one value
- probably two sets of functions - first returns first occurrence of value,
second returns set of occurrenceGee, if only way had some way to return multiple elements of
something... ;PIn other words, I think all of these should actually return an array of
positions. I think it's OK for someone that only cares about the first
instance to just do [1].there can be two functions - "position" - returns first and "positions"
returns all as a array--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
Attachments:
array_offset-02.patchtext/x-patch; charset=US-ASCII; name=array_offset-02.patchDownload+295-24
On 1/20/15 11:12 AM, Pavel Stehule wrote:
I am sending updated version - it allow third optional argument that specify where searching should to start. With it is possible repeatably call this function.
What happened to returning an array of offsets? I think that would be both easier to use than this version as well as performing better.
I see you dropped multi-dimension support, but I think that's fine.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2015-01-20 21:32 GMT+01:00 Jim Nasby <Jim.Nasby@bluetreble.com>:
On 1/20/15 11:12 AM, Pavel Stehule wrote:
I am sending updated version - it allow third optional argument that
specify where searching should to start. With it is possible repeatably
call this function.What happened to returning an array of offsets? I think that would be both
easier to use than this version as well as performing better.
I have still thinking about this idea. It needs a different function and I
didn't start with this.
Implementation a optional start parameter to array_offset is cheap - and I
am thinking so it can be useful for some use cases.
I see you dropped multi-dimension support, but I think that's fine.
It can be implemented later. There is no any barriers to later
implementation.
Show quoted text
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
Hi
with array_offsets - returns a array of offsets
Regards
Pavel
2015-01-20 21:32 GMT+01:00 Jim Nasby <Jim.Nasby@bluetreble.com>:
Show quoted text
On 1/20/15 11:12 AM, Pavel Stehule wrote:
I am sending updated version - it allow third optional argument that
specify where searching should to start. With it is possible repeatably
call this function.What happened to returning an array of offsets? I think that would be both
easier to use than this version as well as performing better.I see you dropped multi-dimension support, but I think that's fine.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
Attachments:
array_offset-03.patchtext/x-patch; charset=US-ASCII; name=array_offset-03.patchDownload+476-24
On 1/24/15 2:48 AM, Pavel Stehule wrote:
with array_offsets - returns a array of offsets
+ <entry>returns a offset of first occurrence of some element in a array. It uses
should be
+ <entry>returns the offset of the first occurrence of some element in an array. It uses+ <entry>returns a array of offset of all occurrences some element in a array. It uses
should be
+ <entry>returns an array of the offsets of all occurrences of some element in an array. It usesAny way to reduce the code duplication between the array and non-array versions? Maybe factor out the operator caching code?
You should remove the array_length() from the last array_offsets test; I don't see that it buys anything.
I think there should be tests for what happens when you feed these functions a multi-dimensional array.
Other than that, looks good.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2015-01-26 23:01 GMT+01:00 Jim Nasby <Jim.Nasby@bluetreble.com>:
On 1/24/15 2:48 AM, Pavel Stehule wrote:
with array_offsets - returns a array of offsets
+ <entry>returns a offset of first occurrence of some element in a array. It uses should be + <entry>returns the offset of the first occurrence of some element in an array. It uses+ <entry>returns a array of offset of all occurrences some element in a array. It uses should be + <entry>returns an array of the offsets of all occurrences of some element in an array. It usesAny way to reduce the code duplication between the array and non-array
versions? Maybe factor out the operator caching code?
I though about it - but there is different checks, different result
processing, different result type.
I didn't find any readable and reduced form :(
You should remove the array_length() from the last array_offsets test; I
don't see that it buys anything.
ok
I think there should be tests for what happens when you feed these
functions a multi-dimensional array.
I can do it. Result should be expected - it searching row by row due MD
format
Other than that, looks good.
Thank you
Pavel
Show quoted text
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
On 1/26/15 4:17 PM, Pavel Stehule wrote:
Any way to reduce the code duplication between the array and non-array versions? Maybe factor out the operator caching code?
I though about it - but there is different checks, different result processing, different result type.
I didn't find any readable and reduced form :(
Yeah, that's why I was thinking specifically of the operator caching code... isn't that identical? That would at least remove a dozen lines...
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2015-01-26 23:29 GMT+01:00 Jim Nasby <Jim.Nasby@bluetreble.com>:
On 1/26/15 4:17 PM, Pavel Stehule wrote:
Any way to reduce the code duplication between the array and
non-array versions? Maybe factor out the operator caching code?I though about it - but there is different checks, different result
processing, different result type.I didn't find any readable and reduced form :(
Yeah, that's why I was thinking specifically of the operator caching
code... isn't that identical? That would at least remove a dozen lines...
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.
Regards
Pavel
Show quoted text
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
On 1/27/15 4:36 AM, Pavel Stehule wrote:
2015-01-26 23:29 GMT+01:00 Jim Nasby <Jim.Nasby@bluetreble.com <mailto:Jim.Nasby@bluetreble.com>>:
On 1/26/15 4:17 PM, Pavel Stehule wrote:
Any way to reduce the code duplication between the array and non-array versions? Maybe factor out the operator caching code?
I though about it - but there is different checks, different result processing, different result type.
I didn't find any readable and reduced form :(
Yeah, that's why I was thinking specifically of the operator caching code... isn't that identical? That would at least remove a dozen lines...
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?
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2015-01-28 0:01 GMT+01:00 Jim Nasby <Jim.Nasby@bluetreble.com>:
On 1/27/15 4:36 AM, Pavel Stehule wrote:
2015-01-26 23:29 GMT+01:00 Jim Nasby <Jim.Nasby@bluetreble.com <mailto:
Jim.Nasby@bluetreble.com>>:On 1/26/15 4:17 PM, Pavel Stehule wrote:
Any way to reduce the code duplication between the array and
non-array versions? Maybe factor out the operator caching code?I though about it - but there is different checks, different
result processing, different result type.I didn't find any readable and reduced form :(
Yeah, that's why I was thinking specifically of the operator caching
code... isn't that identical? That would at least remove a dozen lines...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).
I plan to do some benchmark to calculate if we have to do, or we can use
type cache only.
Pavel
Show quoted text
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.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>>: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).
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2015-02-22 3:00 GMT+01:00 Petr Jelinek <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>>: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
Regards
Pavel
Show quoted text
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Attachments:
array_offset-04.patchtext/x-patch; charset=US-ASCII; name=array_offset-04.patchDownload+477-24
On 22/02/15 12:19, 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>>>: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
You still duplicate the type cache code, but many other array functions
do that too so I will not hold that against you. (Maybe somebody should
write separate patch that would put all that duplicate code into common
function?)
I think this patch is ready for committer so I am going to mark it as such.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
