Re: knngist - 0.8

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: knngist - 0.8
Дата
Msg-id 21255.1287184206@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: knngist - 0.8  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: knngist - 0.8  (Robert Haas <robertmhaas@gmail.com>)
Re: knngist - 0.8  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> I still feel vaguely uneasy about the fact that the proposed patch
> can't handle ASC/DESC or NULLS FIRST/LAST, and that unease grew a bit
> more last night when I read Peter's patch to add collation support.

Good point.

> We could possibly cram ASC/DESC and NULLS FIRST/LAST in by defining
> four new categories of operator strategies rather than one, but
> there's no way that's going to work for collations.  Is there some
> other way to approach this problem?  Can we leave pg_amop as it is,
> and pass the context (sort vs. qual, ASC/DESC, NULLS FIRST/LAST,
> collation, whatever...) to the index via some sort of side channel?

Well, we cannot avoid changing pg_amop, or at least changing its
interpretation, because the current scheme simply can't represent
indexable operators that are used for anything except simple boolean
WHERE tests.  I agree though that we do *not* want pg_amop involved
in the details of exactly what sort ordering is referenced by a sortable
operator.  Somehow that needs to be passed in a side channel.

Maybe we should think in terms of a side channel for Peter's patch
as well.  I share your feeling that trying to propagate collation
the same way we now propagate typmod is a recipe for serious pain.
        regards, tom lane


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: string function - "format" function proposal
Следующее
От: Robert Haas
Дата:
Сообщение: Re: knngist - 0.8