aboutsummaryrefslogtreecommitdiff
path: root/src/fe_utils/string_utils.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2019-01-04 12:16:19 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2019-01-04 12:16:19 -0500
commit4879a5172af01dc05b6350dfa97ea1ac9a4c603c (patch)
treeced2a38e1d8044704529be1581e93843da618984 /src/fe_utils/string_utils.c
parentcb719fa02d828a4a5d1746f4282fdecec51b5656 (diff)
downloadpostgresql-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