On 25 October 2018 at 11:25, David Fetter <david@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