>>>>> "Stephen" == Stephen Frost <sfr...@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 have not 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 should get a >> free pass on the issue. Stephen> This doesn't feel like an attempt to get a free pass on Stephen> anything- it's not being proposed as fully reserved and Stephen> there is spec-defined syntax which needs to be supported. Stephen> If we can get away with keeping it unreserved while not Stephen> making it utterly confusing for users and convoluting the Stephen> code, great, but that doesn't seem 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 select list as a <grouping operation> looks like a function call for any argument types) CUBE, ROLLUP, SETS as unreserved_keyword -- Andrew (irc:RhodiumToad) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
