diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2019-01-04 12:16:19 -0500 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2019-01-04 12:16:19 -0500 |
commit | 4879a5172af01dc05b6350dfa97ea1ac9a4c603c (patch) | |
tree | ced2a38e1d8044704529be1581e93843da618984 /src/fe_utils/string_utils.c | |
parent | cb719fa02d828a4a5d1746f4282fdecec51b5656 (diff) | |
download | postgresql-4879a5172af01dc05b6350dfa97ea1ac9a4c603c.tar.gz postgresql-4879a5172af01dc05b6350dfa97ea1ac9a4c603c.zip |
Support plpgsql variable names that conflict with unreserved SQL keywords.
A variable name matching a statement-introducing keyword, such as
"comment" or "update", caused parse failures if one tried to write
a statement using that keyword. Commit bb1b8f69 already addressed
this scenario for the case of variable names matching unreserved
plpgsql keywords, but we didn't think about unreserved core-grammar
keywords. The same heuristic (viz, it can't be a variable name
unless the next token is assignment or '[') should work fine for
that case too, and as a bonus the code gets shorter and less
duplicative.
Per bug #15555 from Feike Steenbergen. Since this hasn't been
complained of before, and is easily worked around anyway,
I won't risk a back-patch.
Discussion: https://postgr.es/m/15555-149bbd70ddc7b4b6@postgresql.org
Diffstat (limited to 'src/fe_utils/string_utils.c')
0 files changed, 0 insertions, 0 deletions