Re: knngist - 0.8
От | Robert Haas |
---|---|
Тема | Re: knngist - 0.8 |
Дата | |
Msg-id | AANLkTinc4-eO0b24-68ENG2P9tuGOsNiw3PhbEKOjYtw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: knngist - 0.8 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: knngist - 0.8
(Tom Lane <tgl@sss.pgh.pa.us>)
|
Список | pgsql-hackers |
On Fri, Oct 15, 2010 at 7:10 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > 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. What exactly do you mean by that? It has always seemed to me that the operator class mechanism is a complicated abstraction mechanism that actually adds only a very small amount of abstraction. Instead of referring to operators by name or OID we refer to them by a number that maps onto a name or OID. That allows the user to change the name or OID without breaking anything, but that's about it. Perhaps we should think of pg_amop not so much as a way to tell the AM what to do, but just a way to tell it what operator is logically involved without relying on the name or OID. > 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. Yeah. > 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. I'm not sure what you're thinking of here. I think we can have the idea of a FullySpecifiedType = <typid, typmod, collationoid>, but that's not so much a side channel as an abstraction layer. It absolutely won't work to stuff the collations in a global variable or something like that, if that's what you're imagining. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: