| 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: | Whole Thread | Raw Message | 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() |