Open sandroden opened 1 month ago
Confirmed, there is something wrong in CopyAppendNumeric().
Since the on-disk format didn't change for decades (or else pg_upgrade wouldn't work), you can use the 16 pg_filedump also with version 12. The bug will also be there, though.
Thanks @df7cb, is this something will be addresses in a reasonable time or I'm better off not relying on this fix? Please don't take me wrong, this is just to plan my strategies (or surrender... :-)
I'll be looking at it, but I can't promise any deadlines.
Probably worth mentioning that "double precision" type != "numeric" type - although in docs (https://www.postgresql.org/docs/current/datatype-numeric.html) they both are in category Numeric. As for now, pg_filedump does not mention double precision format in the list of supported types. (Although the value changing problem still persists if using "~" to skip the rest of the tuple. Hadn't figure out why yet.)
I'm starting using pg_filedump and it's possible what I report is out of my ignorance rather than a bug, sorry in that case.
I have a simple db, single table, that is a stripped version of real data:
I inspect if with pg_filedump:
quantity ( qta numeric(10,2),) should be 3.00 in the first 3 rows but I read 3.00, 3.E9, 3.E9
if I rerun it w/o any modification I get that number incremented:
Am I wrong in creating the attr list? What is the tuple that is not decoding correctly?
When I'll be able to get consistent outputs I should apply it to the real data that was dump with pg12, should I re-compile it with headers from PostgreSQL 12 or can I just use the pg_filedump I compiled on mu Ubuntu 24:04 with headers form pg16?
Thanks for any hints