>>>>> "Stephen" == Stephen Frost <sfrost@snowman.net> writes:
>>> I'm inclined to think that the audience for this is far larger>>> than the audience for the cube extension, which I
havenot once>>> encountered in the field.
Stephen> +1
Most of my encounters with cube have been me suggesting it to people
on IRC as a possible approach for solving certain kinds of performance
problems by converting them to N-dimensional spatial containment
queries. Sometimes this works well, but it doesn't seem to be an
approach that many people discover on their own.
>> We've jumped through some pretty high hoops to avoid reserving>> keywords in the past, so I don't think this patch
shouldget a>> free pass on the issue.
Stephen> This doesn't feel like an attempt to get a free pass onStephen> anything- it's not being proposed as fully
reservedandStephen> there is spec-defined syntax which needs to be supported.Stephen> If we can get away with keeping
itunreserved while notStephen> making it utterly confusing for users and convoluting theStephen> code, great, but that
doesn'tseem likely to pan out.
Having now spent some more time looking, I believe there is a solution
which makes it unreserved which does not require any significant pain
in the code. I'm not entirely convinced that this is the right
approach in the long term, but it might allow for a more planned
transition.
The absolute minimum seems to be:
GROUPING as a col_name_keyword (since GROUPING(x,y,...) in the selectlist as a <grouping operation> looks like a
functioncall for anyargument types)
CUBE, ROLLUP, SETS as unreserved_keyword
--
Andrew (irc:RhodiumToad)
