On 25 October 2018 at 11:25, David Fetter <da...@fetter.org> wrote: > Digging a teensy bit deeper, I noticed that there's already a > "padding" (space padding, if I understand correctly) system for parts > of the log_line_prefix specification including %m. Did we get painted > into a corner here back in 9.4, when the padding feature was added? > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=4334639f4bb9fb88c13b8dd5faca22b207248504
I'm not sure "painted into a corner" is the right way to think about this. Numerics immediately followed by the '%' are simply already used by the space padding feature. If you want some other modifier then you'll need to invent some other syntax to identify that. It looks like using a '.' after the '%' was mentioned by Alvaro. I think the best way to implement this is to rename process_log_prefix_padding into process_log_prefix_modifiers and add an "int *precision" variable and add some code to parse and populate that based on if there's a '.' found in the prefix. Then in log_line_prefix() just take into account the precision for any prefix variable that it should apply to. So, %s likely should be altered too, although that might require some additional code to NULLify the string if the server config is reloaded, or perhaps you can just remember how much precision that string was made with and only rebuild it if the required precision changes. We don't seem to have any other floating point type prefix variables, so I don't think any of the others need to be altered. > Strangely, there were no tests that came with that either. David, did > you mean to expand it past space padding, or...? Unsure what infrastructure existed then for testing this. I didn't intend to add anything else later. I don't think we have any variables that zero padding would be that useful for, but maybe someone might want to zero pad their pids or xids... ? -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
