On 2024-02-23 at 15:35, Stefan Monnier wrote:

>>> but what are the advantages of journald's representation compared
>>> to a naive one?
>> in short: querability without text parsing. That's about it.
> They have to parse the binary format, so that's not in and of itself
> an upside compared to parsing CSV.
> I've made my share of bad design decisions that don't pan out. But
> there's always an upside to my decision (even when it turns out it 
> speeds up only those cases which can never occur, because of some
> other aspect of the system).
> AFAICT the format is *not* just a plain sequence of log entries, so 
> there's some additional structure which is intended to speed up some
> operations.
> IOW, even if contrived, there should be *some* use case where it
> does better than CSV, no?

I can think of two possibilities, just offhand, in no particular order:

* No need to parse the timestamps, et cetera, and take the risk that
someone put in one that's in a format you don't expect; the times are
stored internally in a consistent guaranteed format, so you can just use
internal reader functions (paired with, and updated alongside, the
internal writer functions) and be done with it.

* No need to worry about handling log entries that *contain* commas, or
whatever other element was chosen as the separator.

   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to