Hi,
I saw you changed my "warn about hidden vars" patch
to ET_ERROR instead of ET_FATAL. My thinking in using
ET_FATAL was that this is an error level that immedately
quits processing and deletes its output file. However,
you are right that we might want to report all such errors
in one run of ECPG.
But if ET_ERROR is used, the output file stays there as if
there was no error. Think about a project that uses Makefile
with say:
.PRECIOUS: %.c
to keep the generated C sources by ECPG. However, the implicit
thinking is that the files were correctly generated.
In such a case, GNU make won't delete the generated file,
and ECPG won't be called the next time "make" is run as
the *.c file already exists (make won't know that ECPG reported
an error code last time) and the C compiler will be called.
directly. GCC on the other hand, deletes its object file
in case of an error (it also reports as many errors as it can),
so running make next time won't attempt linking to a bad
object file.
Attached is the patch to delete the output file if an error
happened. Comments?
Best regards,
Zoltán Böszörményi
--
Bible has answers for everything. Proof:
"But let your communication be, Yea, yea; Nay, nay: for whatsoever is more
than these cometh of evil." (Matthew 5:37) - basics of digital technology.
"May your kingdom come" - superficial description of plate tectonics
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
http://www.postgresql.at/
*** pgsql/src/interfaces/ecpg/preproc/ecpg.c~ 2010-04-03 18:15:53.000000000 +0200
--- pgsql/src/interfaces/ecpg/preproc/ecpg.c 2010-04-03 18:15:53.000000000 +0200
***************
*** 469,474 ****
--- 469,482 ----
fclose(yyin);
if (out_option == 0 && yyout != stdout)
fclose(yyout);
+ /*
+ * If there was an error, delete the output file.
+ */
+ if (ret_value != 0)
+ {
+ if (strcmp(output_filename, "-") != 0 && unlink(output_filename) != 0)
+ fprintf(stderr, _("could not remove output file \"%s\"\n"), output_filename);
+ }
}
if (output_filename && out_option == 0)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
