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
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() |