aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/gist/gistscan.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2020-08-03 09:46:12 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2020-08-03 09:46:12 -0400
commit5f28b21eb3c5c2fb72c24608bc686acd7c9b113c (patch)
treec198f481dbb9eeb7b01d6dc65a5add0a6579d3ac /src/backend/access/gist/gistscan.c
parentb8fdee7d0ca8bd2165d46fb1468f75571b706a01 (diff)
downloadpostgresql-5f28b21eb3c5c2fb72c24608bc686acd7c9b113c.tar.gz
postgresql-5f28b21eb3c5c2fb72c24608bc686acd7c9b113c.zip
Fix behavior of ecpg's "EXEC SQL elif name".
This ought to work much like C's "#elif defined(name)"; but the code implemented it in a way equivalent to endif followed by ifdef, so that it didn't matter whether any previous branch of the IF construct had succeeded. Fix that; add some test cases covering elif and nested IFs; and improve the documentation, which also seemed a bit confused. AFAICS the code has been like this since the feature was added in 1999 (commit b57b0e044). So while it's surely wrong, there might be code out there relying on the current behavior. Hence, don't back-patch into stable branches. It seems all right to fix it in v13 though. Per report from Ashutosh Sharma. Reviewed by Ashutosh Sharma and Michael Meskes. Discussion: https://postgr.es/m/CAE9k0P=dQk9X0cU2tN49S7a9tv733-e1pVdpB1P-pWJ5PdTktg@mail.gmail.com
Diffstat (limited to 'src/backend/access/gist/gistscan.c')
0 files changed, 0 insertions, 0 deletions