On Sat, Jan 2, 2016 at 4:06 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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.
A different angle of attack is to flatten the argument quotes directly in reloptions.c: http://www.postgresql.org/message-id/CAB7nPqTpdGLqLTxuGhBC2GabGNiFRAtLjFbxu=agy1rx_dg...@mail.gmail.com But you did not like that :p -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
