Re: review: More frame options in window functions

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Feb 11, 2010 at 3:26 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> The real question is whether it's time to bite the bullet and stop
>> overloading the opclass infrastructure for semantics-declaration
>> purposes. Are there any other foreseeable cases where we are going
>> to need to add operator knowledge of this sort?

> knngist wants to jimmy with the opclass semantics too, though the need
> there is a little different. The issue is that an amcanorder AM is
> good for optimizing ORDER BY <indexed-column-name>, but that's not
> what GIST indices can do: they can optimize ORDER BY
> <indexed-column-name> <op> <constant>, for suitable values of op.
> Teodor and Oleg handled this by adding a new flag to the AM
> (amcanorderbyop) and adding the operators to the opclass. But, unlike
> the comparison operators, these operators don't necessarily return a
> boolean: in fact they probably don't.

Yeah, but in that case it is reasonable to have the information in
opclasses, because it's directly tied to something you do with indexes,
and it does depend on which opclass the index uses. I don't like the
specific details of what they did, but associating knngist info with
opclasses is sane in the abstract. What's bothering me about the window
frame stuff is that it's not at all associated with an index.

However, what it *is* associated with is a sort ordering, and the notion
that btree opclasses are what define orderings is sufficiently deeply
wired into the system that undoing it would be a huge PITA. So unless
we can see a pretty clear future need for more information in this
category, I'm not really inclined to invent some new structure
altogether. I'm just wondering if anyone does see that...

regards, tom lane