Re: Proposal: Adding json logging
От | David Arnold |
---|---|
Тема | Re: Proposal: Adding json logging |
Дата | |
Msg-id | CAH6vsWLmXsevbmT7XapksFPJMny+CEQi4m+eJ4eaQz7-P2pgqQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Proposal: Adding json logging ("Daniel Verite" <daniel@manitou-mail.org>) |
Ответы |
Re: Proposal: Adding json logging
|
Список | pgsql-hackers |
>To me it's implied by the doc at:
https://www.postgresql.org/docs/current/static/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-CSVLOG
https://www.postgresql.org/docs/current/static/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-CSVLOG
Additionally this still depends on the way some middleware might choose to stream data. Can we really be sure the risk is minimal that any middleware would have chosen to treat new line as an entity delimitator?
Can we even be sure that NO existing middleware would treat newline as a entity delimitator?
I'm not that confident about that.
Anticipating the possible argument, that the "others are wrong": This arguement, though valid, seems sometimes is tought it's limits in very mondane practicability and efficiency needs.
El mar., 17 abr. 2018, 6:55 a.m., Daniel Verite <daniel@manitou-mail.org> escribió:
David Arnold wrote:
> Interesting, does that implicitly mean the whole log event would get
> transmitted as a "line" (with CRLF) in CSV.
To me it's implied by the doc at:
https://www.postgresql.org/docs/current/static/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-CSVLOG
> In the affirmative scenario, this then would work for a true streaming
> aggregator (if CSV was supported).
Assuming a real CSV parser tailing the log, there shouldn't be any trouble
with that.
Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite
В списке pgsql-hackers по дате отправления: