From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Restriction of windows functions |
Date: | 2016-06-17 15:12:18 |
Message-ID: | 21487.1466176338@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru> writes:
> On 17.06.2016 17:01, Tom Lane wrote:
>> IIRC, the sticking point was defining a reasonably datatype-independent
>> (i.e. extensible) notion of distance.
> Why it is not possible just to locate "-" or "+ operator for this type?
Because there's no guarantee that that operator has anything to do with
the sort ordering imposed by the type's btree opclass. We must have a
distance operator that is consistent with the sort order, or the windowing
logic will get hopelessly confused. For that matter, we support multiple
opclasses (sort orderings) per data type, and there's certainly no way
that a single "-" operator will be consistent with all of them.
At the time we discussed extending the definition of a btree opclass to
allow specification of related "+" and "-" operators, but the
infrastructure additions required seemed rather daunting. Now that
we have pg_amop.amoppurpose, it might be easier to add such a concept;
they could be put in with a new "purpose" that shows that they are
not intended as index search operators.
Again, please see the archives. I'm just speaking off the cuff here,
and probably don't remember all the details.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Aleksey Demakov | 2016-06-17 15:17:33 | Experimental dynamic memory allocation of postgresql shared memory |
Previous Message | Teodor Sigaev | 2016-06-17 15:07:37 | Re: Should phraseto_tsquery('simple', 'blue blue') @@ to_tsvector('simple', 'blue') be true ? |