Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Justin Pryzby <pry...@telsasoft.com> writes: > >> This patch has been waiting for input from a committer on the approach I've > >> taken with the patches since March 10, so I'm planning to set to "Ready" - > >> at > >> least ready for senior review. > > I took a quick look through this. This is just MHO, of course: > > * I don't think it's okay to change the existing signatures of > pg_ls_logdir() et al. Even if you can make an argument that it's > not too harmful to add more output columns, replacing pg_stat_file's > isdir output with something of a different name and datatype is most > surely not OK --- there is no possible way that doesn't break existing > user queries.
I disagree that we need to stress over this- we pretty routinely change the signature of various catalogs and functions and anyone using these is already of the understanding that we are free to make such changes between major versions. If anything, we should be strongly discouraging the notion of "don't break user queries" when it comes to administrative and monitoring functions like these because, otherwise, we end up with things like the mess that is pg_start/stop_backup() (and just contrast that to what we did to recovery.conf when thinking about "well, do we need to 'deprecate' or keep around the old stuff so we don't break things for users who use these functions?" or the changes made in v10, neither of which have produced much in the way of complaints). Let's focus on working towards cleaner APIs and functions, accepting a break when it makes sense to, which seems to be the case with this patch (though I agree about using a TAP test suite and about performing the directory recursion in C instead), and not pull forward cruft that we then are telling ourselves we have to maintain compatibility of indefinitely and at the expense of sensible APIs. Thanks, Stephen
signature.asc
Description: PGP signature