On Fri, Oct 4, 2013 at 3:53 AM, Marko Tiikkaja <marko@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
