>> I agree, the contrib/cube patch as posted is purely so we could test >> everything without having to argue over the new name first.
Tom> I wonder if you've tried hard enough to avoid reserving the keyword.
GROUP BY cube(a,b) is currently legal syntax and means something completely incompatible to what the spec requires.
GROUP BY GROUPING SETS (cube(a,b), c) -- is that cube(a,b) an expression to group on, or a list of grouping sets to expand?
GROUP BY (cube(a,b)) -- should that be an error, or silently treat it as a function call rather than a grouping set? What about GROUP BY GROUPING SETS ((cube(a,b)) ? (both are errors in our patch)
Accepting those as valid implies a degree of possible confusion that I personally regard as quite questionable. Previous discussion seemed to have accepted that contrib/cube was going to have to be renamed.
Tom> I think that the cube extension is not going to be the only Tom> casualty if "cube" becomes a reserved word --- that seems like a Tom> name that could be in use in lots of applications. ("What do Tom> you mean, 9.5 breaks our database for tracking office space?") Tom> It would be worth quite a bit of effort to avoid that.
It has been a reserved word in the spec since, what, 1999? and it is a reserved word in mssql, oracle, db2, etc.?
It only needs to be a col_name_keyword, so it still works as a table or column name (as usual we are less strict than the spec in that respect). I'm looking into whether it can be made unreserved, but I have serious doubts about this being a good idea.
+1
contrib module should be renamed - more - current name is confusing against usual functionality related to words CUBE and ROLLUP