On Thu, Aug 21, 2014 at 1:13 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Andrew Gierth <and...@tao11.riddles.org.uk> writes: >> "Tom" == Tom Lane <t...@sss.pgh.pa.us> writes: >> 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. > > Well, if there are any extant applications that use that exact phrasing, > they're going to be broken in any case. That does not mean that we have > to break every other appearance of "cube". I think that special-casing > appearances of cube(...) in GROUP BY lists might be a feasible approach. > > Basically, I'm afraid that unilaterally renaming cube is going to break > enough applications that there will be more people who flat out don't > want this patch than there will be who get benefit from it, and we end > up voting to revert the feature altogether. If you'd like to take that > risk then feel free to charge full steam ahead, but don't say you were > not warned. And don't bother arguing that CUBE is reserved according to > the standard, because that will not make one damn bit of difference > to the people who will be unhappy.
I have to respectfully disagree. Certainly, if there is some reasonable way to not have to change 'cube' then great. But the tonnage rule applies here: even considering compatibility issues, when considering the importance of standard SQL (and, I might add, exceptionally useful) syntax and a niche extension, 'cube' is going to have to get out of the way. There are view valid reasons to break compatibility but blocking standard syntax is definitely one of them. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
