Re: Tom Lane 2017-12-16 <417.1513438031@sss.pgh.pa.us>
> I think we're talking at cross-purposes. I'm not saying we should not fix
> this problem. I'm saying that the proposed fix appears incomplete, which
> means that (a) even if it solves your problem, it probably does not solve
> related problems for other people; (b) since it's not clear why this
> patch is apparently sufficient for you, I'd like to understand that in
> some detail before deeming the problem solved; and (c) leaving instances
> of the problematic code in our tree is just about guaranteed to mean
> you'll have the same problem in future, when somebody either copies that
> coding pattern into some new script or tweaks the way those existing
> scripts are being used.
Grepping through the source, there are three places where $0 printed
to files in regular operation (as opposed to being used in --help):
* src/backend/catalog/genbki.pl
* It has been GENERATED by $0
* src/backend/utils/Gen_fmgrtab.pl
* It has been GENERATED by $0
* src/backend/utils/mb/Unicode/convutils.pm, a perl module used by
src/backend/utils/mb/Unicode/*_to_*.pl
my $this_script = $0;
print $out "/* This file is generated by $this_script */\n\n";
The latter is not relevant because the generated .map files just
included in other .c files, but not shipped in source. (And a changed
comment does not modify the build result.)
The first case is fixed in my original patch, the updated patch
catches the second as well.
I believe the reason why we've only been seeing half of the problem
yet is that the generated files are shipped with the tarballs, so it
might be a timestamping issue determining if the scripts are
re-executed.
Filed as https://commitfest.postgresql.org/16/1417/
Christoph
--
Senior Berater, Tel.: +49 2166 9901 187
credativ GmbH, HRB Mönchengladbach 12080, USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer
pgp fingerprint: 5C48 FE61 57F4 9179 5970 87C6 4C5A 6BAB 12D2 A7AE