From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Chapman Flack <jcflack(at)acm(dot)org> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Adding the extension name to EData / log_line_prefix |
Date: | 2024-05-15 17:07:58 |
Message-ID: | 20240515170758.42zdk3czhhldecv7@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2024-05-15 17:42:58 | Re: [PATCH] Add --syntax to postgres for SQL syntax checking |
Previous Message | Robert Haas | 2024-05-15 16:58:34 | Re: Fix log_line_prefix to display the transaction id (%x) for statements not in a transaction block |