Re: best place for "rtree" strategy numbers

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: best place for "rtree" strategy numbers
Дата
Msg-id 22970.1431646949@sss.pgh.pa.us
обсуждение исходный текст
Ответ на best place for "rtree" strategy numbers  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: best place for "rtree" strategy numbers  (Alvaro Herrera <alvaro.herrera@2ndquadrant.com>)
Список pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> In Emre Hasegeli's patch for range/inet/geometry opclasses for BRIN, he
> chose to move strategy numbers from gist.h to a more central place.  He
> chose skey.h because that's where btree strategy numbers are defined,
> but I'm not sure I agree with that choice.

Yeah, putting those in skey.h was probably not such a great idea.
(IIRC, they didn't use to be there ... it's probably my fault that
they're there now.)

> Therefore I would like to move those numbers elsewhere.  Maybe we could
> have a new file which would be used only for strategy numbers, such as
> src/include/access/stratnum.h, and we would have something like this,
> and redefine the ones elsewhere to reference those.

+1

> I can, of course, just leave these files well enough alone and just rely
> on the numbers not changing (which surely they won't anyway) and
> remaining consistent with numbers used in new opclasses (which surely
> they will lest they be born inconsistent with existing ones).

Yeah, we do have checks in opr_sanity which will complain if inconsistent
strategy numbers are used for similarly-named operators.  That's a pretty
weak test though, and operator names aren't exactly the right thing to
check anyway.  I'd be good with pushing all of that stuff to a new central
header.
        regards, tom lane



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

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: KNN-GiST with recheck
Следующее
От: Kouhei Kaigai
Дата:
Сообщение: Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API)