Re: Adding the extension name to EData / log_line_prefix - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Adding the extension name to EData / log_line_prefix
Date
Msg-id 20240515170758.42zdk3czhhldecv7@awork3.anarazel.de
Whole thread Raw
In response to Re: Adding the extension name to EData / log_line_prefix  (Chapman Flack <jcflack@acm.org>)
Responses Re: Adding the extension name to EData / log_line_prefix
List pgsql-hackers
Hi,

On 2024-05-15 12:54:45 -0400, Chapman Flack wrote:
> On 05/15/24 11:50, Tom Lane wrote:
> > Hmm, cute idea, but it'd only help for extensions that are
> > NLS-enabled.  Which I bet is a tiny fraction of the population.
> > So far as I can find, we don't even document how to set up
> > TEXTDOMAIN for an extension --- you have to cargo-cult the
> 
> But I'd bet, within the fraction of the population that does use it,
> it is already a short string that looks a whole lot like the name
> of the extension. So maybe enhancing the documentation and making it
> easy to set up would achieve much of the objective here.

The likely outcome would IMO be that some extensions will have the data,
others not. Whereas inferring the information from our side will give you
something reliable.

But I also just don't think it's something that architecturally fits together
that well. If we either had TEXTDOMAIN reliably set across extensions or it'd
architecturally be pretty, I'd go for it, but imo it's neither.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Fix log_line_prefix to display the transaction id (%x) for statements not in a transaction block
Next
From: Robert Haas
Date:
Subject: Re: [PATCH] Add --syntax to postgres for SQL syntax checking