Re: Adding the extension name to EData / log_line_prefix

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Chapman Flack <jcflack(at)acm(dot)org>, 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 21:14:18
Message-ID: 20240515211418.d3aulqz62wb4zzrx@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2024-05-15 13:45:30 -0400, Tom Lane wrote:
> 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.

Maybe I missing something here. Even adding those two lines to the extensions
in core and contrib is going to end up being more lines than what I proposed?

What portability issues do you forsee? We already look up the same symbol in
all the shared libraries ("Pg_magic_func"), so we know that we can deal with
duplicate function names. Are you thinking that somehow we'd end up with
symbol interposition or something?

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2024-05-15 21:24:53 Re: Adding the extension name to EData / log_line_prefix
Previous Message Nathan Bossart 2024-05-15 21:10:39 Re: recovery modules