Re: logfmt and application_context

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Étienne BERSAC <etienne(dot)bersac(at)dalibo(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: logfmt and application_context
Date: 2023-09-27 08:14:48
Message-ID: 8BB6D24F-208E-4DB9-BD0E-94F177B9B927@yesql.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 26 Sep 2023, at 09:56, Étienne BERSAC <etienne(dot)bersac(at)dalibo(dot)com> wrote:
> Le mardi 05 septembre 2023 à 11:35 +0200, Daniel Gustafsson a écrit :
>>> On 30 Aug 2023, at 14:36, Étienne BERSAC <etienne(dot)bersac(at)dalibo(dot)com> wrote:
>>
>>> ..what do you think of having logfmt output along json and CSV ?
>>
>> Less ideal is
>> that there is no official formal definition of what logfmt is [...] If we add
>> support for it, can we reasonably expect that what we emit is what consumers of
>> it assume it will look like?
>
> I didn't know logfmt had variation. Do you have a case of
> incompatibility ?

Like I said upthread, it might be reasonable to assume that the format is
fairly stable, but without a formal definition there is no way of being
certain. Formats without specifications that become popular tend to diverge,
Markdown being the textbook example.

Being a common format in ingestion tools makes it interesting though, but I
wonder if those tools aren't alreday supporting CSV such that adding logfmt
won't move the compatibility markers much?

--
Daniel Gustafsson

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2023-09-27 08:21:29 Re: [PATCH] Add inline comments to the pg_hba_file_rules view
Previous Message Michael Paquier 2023-09-27 08:08:23 Re: pg_stat_get_activity(): integer overflow due to (int) * (int) for MemoryContextAllocHuge()