]> granicus.if.org Git - postgresql/commit - src/bin/psql/common.c
Fix tracking of psql script line numbers during \copy from another place.
authorTom Lane <tgl@sss.pgh.pa.us>
Mon, 10 Mar 2014 19:47:06 +0000 (15:47 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Mon, 10 Mar 2014 19:47:40 +0000 (15:47 -0400)
commite85a5ffba8ae559b612b6fbc07acf1b16636887e
tree51cb895078f2ff334c53c30de7177b7869c8cd83
parent8722017bbcbc95e311bbaa6d21cd028e296e5e35
Fix tracking of psql script line numbers during \copy from another place.

Commit 08146775acd8bfe0fcc509c71857abb928697171 changed do_copy() to
temporarily scribble on pset.cur_cmd_source.  That was a mighty ugly bit of
code in any case, but in particular it broke handleCopyIn's ability to tell
whether it was reading from the current script source file (in which case
pset.lineno should be incremented for each line of COPY data), or from
someplace else (in which case it shouldn't).  The former case still worked,
the latter not so much.  The visible effect was that line numbers reported
for errors in a script file would be wrong if there were an earlier \copy
that was reading anything other than inline-in-the-script-file data.

To fix, introduce another pset field that holds the file do_copy wants the
COPY code to use.  This is a little bit ugly, but less so than passing the
file down explicitly through several layers that aren't COPY-specific.

Extracted from a larger patch by Kumar Rajeev Rastogi; that patch also
changes printing of COPY command tags, which is not a bug fix and shouldn't
get back-patched.  This particular idea was from a suggestion by Amit
Khandekar, if I'm reading the thread correctly.

Back-patch to 9.2 where the faulty code was introduced.
src/bin/psql/common.c
src/bin/psql/copy.c
src/bin/psql/settings.h
src/bin/psql/startup.c