Re: plpgsql.print_strict_params

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