From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Teodor Sigaev <teodor(at)sigaev(dot)ru>, Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: knngist - 0.8 |
Date: | 2010-10-15 23:10:06 |
Message-ID: | 21255.1287184206@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-10-15 23:49:01 | Re: knngist - 0.8 |
Previous Message | Bernd Helmle | 2010-10-15 23:04:33 | Re: Re: starting to review the Extend NOT NULL representation to pg_constraint patch |