Heikki Linnakangas <heikki@enterprisedb.com> writes:
>> I am implementing a technique that sorts a result set according to weight annotations in the WHERE.
>>
>> The query
>>
>> SELECT * FROM cars
>> WHERE (cdChanger=1){2}
>> OR (mp3player=1){1}
>>
>> would be sorted according to partial conditions that hold.
> You could do that like this, with no need to hack the backend:
> SELECT * FROM cars
> WHERE (cdChanger=1)
> OR (mp3player=1)
> ORDER BY (CASE WHEN cdchanger=1 THEN 2 ELSE 0 END) +
> (CASE WHEN mp3player=1 THEN 1 ELSE 0 END) DESC;
If that's an accurate description of the goal, then the OP is nuts to
insist on doing it in the executor. A reasonable implementation would
be to generate the required ORDER BY at rewrite time, which is before
the planner starts to fold spindle & mutilate the WHERE clause, so the
problem of needing access to the original WHERE structure is solved.
I see no need to change either the planner or the executor one bit.
As for the tree representation of this, rather than modifying AExpr
or OpExpr and trying to deal with the resulting fallout, it might be
better to invent a new expression node type: something{w} becomes
struct OrderingWeight { Node *something; int weight;}
Or maybe weight is another Node --- are run-time-variable weights
allowed? Anyway, plugging a new node type into the system is a
straightforward if tedious exercise, and there are plenty of past
patches to look at as models.
regards, tom lane
