On Thu, Jan 23, 2020 at 1:22 PM Bruce Momjian <br...@momjian.us> wrote: > Yes, good point. I think my one concern is that someone might specify > both keys in the JSON, which would be very odd.
I think that if a tool other than PostgreSQL chooses to generate a PostreSQL backup manifest, it must take care to do it in a manner that is compatible with what PostgreSQL would generate. If it doesn't, well, that sucks for them, but we can't prevent other people from writing bad code. On a very good day, we can prevent ourselves from writing bad code. There is in general the question of how rigorous PostgreSQL ought to be when validating a backup manifest. The proposal on the table is to store four (4) fields per file: name, size, last modification time, and checksum. So a JSON object representing a file should have four keys, say "path", "size", "mtime", and "checksum". The "checksum" key could perhaps be optional, in case the user disables checksums, or we could represent that case in some other way, like "checksum" => null, "checksum" => "", or "checksum" => "NONE". There is an almost unlimited scope for bike-shedding here, but let's leave that to one side for the moment. Suppose that someone asks PostgreSQL's backup manifest verification tool to validate a backup manifest where there's an extra key. Say, in addition to the four keys listed in the previous paragraph, there is an additional key, "momjian". On the one hand, our backup manifest verification tool could take this as a sign that the manifest is invalid, and accordingly throw an error. Or, it could assume that some third-party backup tool generated the backup manifest and that the "momjian" field is there to track something which is of interest to that tool but not to PostgreSQL core, in which case it should just be ignored. Incidentally, some research seems to suggest that the problem of filenames which don't form a valid UTF-8 sequence cannot occur on Windows. This blog post may be helpful in understanding the issues: http://beets.io/blog/paths.html -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
