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@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
