I wrote: > Now, one line of thought here is that flatten_reloptions() is out of its > mind to not be worrying about quoting the reloption values. And perhaps > it is, but I think if we go that direction, we may be fighting similar > fires for awhile to come. psql's describe.c, for example, doesn't worry > about quoting anything when printing reloptions, and there's likely > similar code in third-party clients. Also, a solution like this would > do nothing for existing dump files.
> The other line of thought is that we're already making an effort to allow > any keyword to appear as the value of a def_arg, and maybe we should try > to make that work 100% instead of only 90%.
After further thought I believe that the right thing to do is pursue both these lines of attack. Adding quoting in flatten_reloptions() seems like a safely back-patchable fix for the original complaint, and it's really necessary anyway for reloption values that don't look like either an identifier or a number. The grammar allows any arbitrary string constant to be the original form of a reloption, and we have no good reason to assume that extension modules will constrain their custom reloptions to be one or the other. (I'm thinking we'd better be prepared to double-quote the option names, too, just in case.)
The grammar fixes seem like a good thing to do in the long run, too, but there's little need to risk back-patching it since accepting col_name_keywords without quoting would be mostly a convenience issue.
All seems reasonable.
--
Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
