Re: unused_oids script is broken with bsd sed

Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Apr 26, 2018 at 11:29 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Personally, I use ccache which doesn't seem to care too much, but I agree
>> than in some usages, extra touches of headers would be costly.  Perhaps
>> it's worth adding logic to avoid overwriting an existing output file
>> unless it changed?  I'm not sure; that would cost something too.

> It seems like a good idea to me.

I took a quick look into this.  It's very easy to do so far as the Perl
code is concerned: just teach Catalog::RenameTempFile that if the target
file already exists, run File::Compare::compare to see if its contents are
identical to the temp file, and if so unlink the temp file rather than
renaming.  I've tried this, it works, and I can't measure any difference
in the runtime of genbki.pl (at least on my usual dev machine).  So it
seems like there's little downside.

However, RenameTempFile is also used by Gen_fmgrtab.pl, and having the
same sort of no-touch semantics for fmgroids.h and friends would have some
additional fallout.  The makefiles would think they have to keep
re-running Gen_fmgrtab.pl if fmgroids.h is older than the mod time on any
input file, and that's certainly no good.  We can fix that by inventing a
stamp file for the Gen_fmgrtab.pl run, analogous to bki-stamp for the
genbki.pl run, but that means changes in the makefiles that go a bit
beyond the realm of triviality.

A compromise answer is to arrange things so that genbki.pl has no-touch
semantics but Gen_fmgrtab.pl doesn't, requiring either two support
functions in Catalog.pm or an extra argument to RenameTempFile.  But
that's really ugly.  Besides, if we're trying to avoid excess recompiles
due to useless touches of common header files, then failing to have
no-touch behavior for fmgroids.h is leaving a lot of money on the table.
So I don't like that answer at all.

Anyway, I'm happy to go make this happen; it looks like only another hour
or so's worth of work to fix the makefiles.  But I wonder if anyone will
say this is too much churn for post-feature-freeze and we should shelve
it till v12.

			regards, tom lane