On Sun, Jan 22, 2023 at 07:19:41PM +0100, Tomas Vondra wrote: > On 1/21/23 19:53, Egor Rogov wrote: > > Hi Tomas, > > On 21.01.2023 00:50, Tomas Vondra wrote: > >> This simply adds two functions, accepting/producing anyarray - one for > >> lower bounds, one for upper bounds. I don't think it can be done with a > >> plain subquery (or at least I don't know how). > > > > Anyarray is an alien to SQL, so functions are well justified here. What > > makes me a bit uneasy is two almost identical functions. Should we > > consider other options like a function with an additional parameter or a > > function returning an array of bounds arrays (which is somewhat > > wasteful, but probably it doesn't matter much here)? > > > > I thought about that, but I think the alternatives (e.g. a single > function with a parameter determining which boundary to return). But I > don't think it's better.
What about a common function, maybe called like: ranges_upper_bounds(PG_FUNCTION_ARGS) { AnyArrayType *array = PG_GETARG_ANY_ARRAY_P(0); Oid element_type = AARR_ELEMTYPE(array); TypeCacheEntry *typentry; /* Get information about range type; note column might be a domain */ typentry = range_get_typcache(fcinfo, getBaseType(element_type)); return ranges_bounds_common(typentry, array, false); } That saves 40 LOC. Shouldn't this add some sql tests ? -- Justin