> However, since there's no standard strftime escape for epoch, > Robert's proposal to rip out the functionality would break any existing > code that still depends on this formatting option. I can't say that > there is any, but by the same token he can't say there isn't.
Absolutely - so the question is, is it worth the possibility of breaking backward compatibility to get the benefit of being able to work with an external log rotator? I think it is. It's hard for me to believe that the base of people who want to have the epoch automatically appended to their log file name is very large. The only use-case I can see for this behavior is if you wanted to make sure that every postmaster start got its own logfile but you didn't really care what those logfiles were called. But even if that's your situation, why wouldn't you just use the default value in postgresql.conf, which will also generate a new filename each time? On the other hand, it's easy for me to believe that a lot of people want to use external log rotators. I think it certainly merits some mention in the release notes. But I can't believe you'll get too many complaints. Even if people do have to change a script or something, that's a pretty easy recovery compared to what they'll have to do when they issue one of those fancy new TRUNCATE commands that are now recursive. (Oh, yeah, at the end of every month I run this script - it creates a new inherited table, moves all of the data from the parent table to the new inherited table, and then truncates the parent....) ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
