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

From Tom Lane
Subject Re: Adding the extension name to EData / log_line_prefix
Date
Msg-id 1802472.1715795130@sss.pgh.pa.us
Whole thread Raw
In response to Re: Adding the extension name to EData / log_line_prefix  (Andres Freund <andres@anarazel.de>)
Responses Re: Adding the extension name to EData / log_line_prefix
Re: Adding the extension name to EData / log_line_prefix
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2024-05-15 12:54:45 -0400, Chapman Flack wrote:
>> 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.

There is one advantage over my suggestion of changing PG_MODULE_MAGIC:
if we tell people to write

   PG_MODULE_MAGIC;
   #undef TEXTDOMAIN
   #define TEXTDOMAIN PG_TEXTDOMAIN("hstore")

then that's 100% backwards compatible and they don't need any
version-testing ifdef's.

I still think that the kind of infrastructure Andres proposes
is way overkill compared to the value, plus it's almost certainly
going to have a bunch of platform-specific problems to solve.
So I think Peter's thought is worth pursuing.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [PATCH] Add --syntax to postgres for SQL syntax checking
Next
From: Chapman Flack
Date:
Subject: Re: Adding the extension name to EData / log_line_prefix