2009/4/28 Tom Lane
<tgl@sss.pgh.pa.us>Well, you've omitted showing us the code where the problem is likely to
be, but I am kinda thinking that you've shot yourself in the foot by
trying to represent your special ordering clause as a simple constant.
The planner is quite smart enough to throw away "order by constant"
as a no-op. By the time you get down to the pathkey logic it's just
going to be ignoring that clause entirely; and if you try to brute-force
it you're more than likely going to break something.
Well, I know I'm breaking something, because when I execute "\d" in psql, the server hangs out.
When I performs the order by clause, I call a function in transformSelectStmt on analyze.c (This is parse->hasGrMemb, that I call in grouping_planner ) :
qry->hasGrMemb = hassSortByGrMemb(stmt->sortClause);
|****************************************************************************************************|
Then the function is this (on parse_clause.c):
//To know if the query has an ORDER BY grmemb
bool
hassSortByGrMemb(List *orderlist){
ListCell *olitem;
bool result;
result=false;
foreach(olitem, orderlist)
{
SortBy *sortby = lfirst(olitem);
char *namegrmemb = strVal(linitial(((ColumnRef *) sortby->node)->fields));
if (strcmp(namegrmemb, "grmemb")==0)
result=true;
}
return result;
}
Rather than kluging up any of this code, I wonder whether you couldn't
represent your fuzzy sorting requirement as ORDER BY some_function(...)
and put all the smarts into that function.
Well, the project force me to include all the source in the core. That is why I wanna know if there's any chance that I could sort the final resultSlot?.
regards
