On 4/5/18, Tom Lane <t...@sss.pgh.pa.us> wrote: > Something that bothered me a bit while writing the warning-producing code > is that showing %bki_values isn't actually that great a way of identifying > the trouble spot. By this point we've expanded out defaults and possibly > replaced some other macros, so it doesn't look that much like what was > in the .dat file. I think what would be ideal, both here and in some > other places like AddDefaultValues, is to be able to finger the location > of the bad tuple by filename and line number, but I have no idea whether > it's practical to annotate the tuples with that while reading the .dat > files. Any thoughts?
We could use the $. variable to save the line number, which is what the old code had. AddDefaultValues will report the line number on failure, so I left out explicit line number reporting. If memory serves, Perl is sensitive to how you format the "die" message. If I delete a default value from the header, I get this, reporting line 16: Failed to form full tuple for pg_opfamily Missing values for: opfnamespace Showing other values for context: oid => 421, opfmethod => 403, opfowner => PGUID, opfname => abstime_ops, at ../../../src/backend/catalog/Catalog.pm line 259, <$ifd> line 16. Makefile:23: recipe for target 'reformat-dat-files' failed make: *** [reformat-dat-files] Error 25 I think the context is good for pg_attribute, because there is no file to read from. I'll think about the lookup code. -John Naylor