>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
Tom> Perhaps so. I would really prefer not to have to get intoTom> estimating how many people will be inconvenienced
howbadly.Tom> It's clear to me that not a lot of sweat has been put intoTom> seeing if we can avoid reserving the
keyword,and I think weTom> need to put in that effort.
So, first nontrivial issue that crops up is this: if CUBE is
unreserved, then ruleutils will output the string "cube(a,b)" for a
function call to a function named "cube", on the assumption that it
will parse back as a single unit (which inside a GROUP BY is not
true).
Options:
1) when outputting GROUP BY clauses (and nothing else), put parens
around anything that isn't provably atomic; or put parens around
anything that might look like a function call; or put parens around
anything that looks like a function call with a keyword name
2) when outputting any function call, add parens if the name is an
unreserved keyword
3) when outputting any function call, quote the name if it is an
unreserved keyword
4) something else?
(This of course means that if someone has a cube() function call in
a group by clause of a view, then upgrading will change the meaning
of the view and possibly fail to create it; there seems to be no fix
for this, not even using the latest pg_dump, since pg_dump relies on
the old server's ruleutils)
--
Andrew (irc:RhodiumToad)
