Re: GiST for range types (was Re: Range Types - typo + NULL string constructor)

Поиск
Список
Период
Сортировка
От Alexander Korotkov
Тема Re: GiST for range types (was Re: Range Types - typo + NULL string constructor)
Дата
Msg-id CAPpHfduORTpMLB=Lxi5eDEjx8mfvy2g7=wKyN83iXxKHW0P3+Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: GiST for range types (was Re: Range Types - typo + NULL string constructor)  (Jeff Davis <pgsql@j-davis.com>)
Ответы Re: GiST for range types (was Re: Range Types - typo + NULL string constructor)
Re: GiST for range types (was Re: Range Types - typo + NULL string constructor)
Список pgsql-hackers
Hi!

On Mon, Oct 17, 2011 at 12:38 PM, Jeff Davis <pgsql@j-davis.com> wrote:
> I started implementing subtype_diff, and I noticed that it requires
> defining an extra function for each range type. Previously, the numeric
> types could just use a cast, which was convenient for user-defined range
> types.
>
> If you have any other ideas to make that cleaner, please let me know.
> Otherwise I'll just finish implementing subtype_diff.
I think implementing subtype_diff for each datatype is ok.  We could implement some universal function based on minus operator and casting to double precision. But such solution might be unacceptable in both predictability (operator and casting function might do not the things we expect) and performance.

I'm beginning to think that we should just allow the user to specify
their own gist_penalty function. Specifying just the subtype_diff
doesn't save much time, and it can only be limiting. Additionally, it's
harder for users to understand the purpose of the function.
If we allow user to specify own gist_penalty function, then such function should deal with:
1) GiST-specific data structures such as GISTENTRY.
2) Decomposing ranges using range_deserialize.
3) Inifinities, which we could handle in general penalty functions.
Thats why I prefere to implement subtype_diff.

------
With best regards,
Alexander Korotkov. 

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

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: Updated version of pg_receivexlog
Следующее
От: Robert Haas
Дата:
Сообщение: Re: ALTER TABLE ONLY ...DROP CONSTRAINT is broken in HEAD.