On Fri, Oct 4, 2013 at 3:53 AM, Marko Tiikkaja <ma...@joh.to> wrote: > I don't think there has. > > I originally had more ideas for options which you could turn on/off, which I > believe might have justified reserving them, but I'm not sure any of those > will ever happen, at least not as a simple on/off option. Did you have a > better idea for the syntax? The only thing I can think of is > print_strict_params and no_print_strict_params, and I'm not very fond of > that.
Yeah, that doesn't seem good. How about writing the grammar production as '#' K_PRINT_STRICT_PARAMS option_value where option_value := T_WORD | unreserved_keyword; Then you don't need to make ON and OFF keywords; you can just use strcmp() against the option_value and either throw an error, or set the flag appropriately. > Also, in what contexts are unreserved keywords a problem in modern PL/PgSQL? I am not sure I've found all cases where this can matter, but what I did is flipped through the grammar in less, looking for T_WORD, and checking for productions where T_WORD was allowed but unreserved_keyword was not. I found getdiag_target, for_variable, stmt_execsql, and cursor_variable. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
