From: | "Daniel Verite" <daniel(at)manitou-mail(dot)org> |
---|---|
To: | "David Arnold" <dar(at)xoe(dot)solutions> |
Cc: | "Christophe Pettus" <xof(at)thebuild(dot)com>,"John W Higgins" <wishdev(at)gmail(dot)com>,pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Proposal: Adding json logging |
Date: | 2018-04-16 18:27:59 |
Message-ID: | 6d0a1374-13af-40ad-aed9-93fb8bd087bb@manitou-mail.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
David Arnold wrote:
> Not claiming this assumption does imply parsing of a *rolling* set
> of log lines with *previously unkown cardinality*. That's expensive
> on computing resources. I don't have actual numbers, but it doesn't
> seem too far fetched, neither.
> I filed a question to the author of fluent-bit to that extend which
> you can consult here:
> https://github.com/fluent/fluent-bit/issues/564 Let's see what
> Eduardo has to inform us about this...
fluent-bit does not appear to support CSV, as mentioned in
https://github.com/fluent/fluent-bit/issues/459
which got flagged as an enhancement request some time ago.
In CSV a line break inside a field is easy to process for
a parser, because (per https://tools.ietf.org/html/rfc4180)
"Fields containing line breaks (CRLF), double quotes, and commas
should be enclosed in double-quotes"
So there is no look ahead to do. In a character-by-character loop,
when encountering a line break, either the current field did not
start with a double quote and the line break is part of the content, or it
did
start with a double quote and the line break ends the current record.
What doesn't quite work is to parse CSV with a regex, it's
discussed in some detail here for instance:
https://softwareengineering.stackexchange.com/questions/166454/can-the-csv-format-be-defined-by-a-regex
Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite
From | Date | Subject | |
---|---|---|---|
Next Message | Guilherme Pereira | 2018-04-16 18:40:48 | Re: very slow queries when max_parallel_workers_per_gather is higher than zero |
Previous Message | Alexander Lakhin | 2018-04-16 17:12:45 | Re: Overcoming SELECT ... FOR UPDATE permission restrictions |