Re: proposal: searching in array function - array_position

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Petr Jelinek <petr(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: searching in array function - array_position
Date: 2015-03-10 22:20:20
Message-ID: 54FF6E24.2020808@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 3/10/15 2:43 PM, Pavel Stehule wrote:
>
> There is not all that much commonality; many functions don't bother to
> populate all of the ArrayMetaState fields because they don't need all of
> them. (The ones you quote don't, in fact.) You are either going to end
> up with a subroutine that does extra syscache lookups to populate the
> whole struct every time, or a confusing collection of ad-hoc
> subroutines.
> I'm not convinced that there's a lot of mileage to be gained here.
>
>
> I have not good feeling about it too. If we would to enhance this are,
> we probably need a specific flinfo field and flags to specify more
> precious the context of cached informations. my_extra should be reserved
> for generic usage. But still there is relative big space for settings
> some less common fields like "proc".
>
> With extra field in flinfo we can have interface like
>
> bool set_flinfo_type_cache(fcinfo, type, flags);
> and usage fcinfo->flinfo->typecache->typlen, ..

I'm not following what you intended there, but in any case I don't think
we'd need to change all that much, because there's only 3 cases:

1) Get only the base type info
2) Get base type info and equality operator
3) Get IO info for one IOFunc

Passing the function an enum (and perhaps keeping it in ArrayMetaState)
would be enough to distinguish between the 3 cases. You'd also need to
pass in IOFuncSelector.

That said, this pattern with fn_extra is repeated a lot, even just in
the backend (not counting contrib or extensions). It would be nice if
there was generic support for this.

decibel(at)decina:[17:15]~/pgsql/HEAD/src/backend (array_offset_v4
$)$pg_grep fn_extra|cut -d: -f1|uniq -c
14 access/gist/gistscan.c
7 executor/functions.c
1 executor/nodeWindowAgg.c
14 utils/adt/array_userfuncs.c
31 utils/adt/arrayfuncs.c
4 utils/adt/domains.c
2 utils/adt/enum.c
1 utils/adt/int.c
6 utils/adt/jsonfuncs.c
1 utils/adt/oid.c
4 utils/adt/orderedsetaggs.c
7 utils/adt/rangetypes.c
24 utils/adt/rowtypes.c
8 utils/adt/varlena.c
(utils/fmgr/* doesn't count)
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-03-10 22:25:50 Re: proposal: searching in array function - array_position
Previous Message Heikki Linnakangas 2015-03-10 22:14:58 Re: pg_rewind in contrib