Re: proposal: searching in array function - array_position

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: proposal: searching in array function - array_position
Дата
Msg-id 54FF6E24.2020808@BlueTreble.com
обсуждение исходный текст
Ответ на Re: proposal: searching in array function - array_position  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: proposal: searching in array function - array_position  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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@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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: pg_rewind in contrib
Следующее
От: Tom Lane
Дата:
Сообщение: Re: proposal: searching in array function - array_position