Re: knngist - 0.8
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Teodor Sigaev <teodor@sigaev.ru>, Oleg Bartunov <oleg@sai.msu.su>, Pgsql Hackers <pgsql-hackers@postgresql.org>
Date: 2010-10-15T23:10:06Z
Lists: 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