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
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 |