Re: Adding the extension name to EData / log_line_prefix

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Adding the extension name to EData / log_line_prefix
Дата
Msg-id 1784552.1715788252@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Adding the extension name to EData / log_line_prefix  (Peter Eisentraut <peter@eisentraut.org>)
Ответы Re: Adding the extension name to EData / log_line_prefix
Re: Adding the extension name to EData / log_line_prefix
Список pgsql-hackers
Peter Eisentraut <peter@eisentraut.org> writes:
> On 14.05.24 01:11, Tom Lane wrote:
>> The mechanism that Andres describes for sourcing the name seems a bit
>> overcomplex though.  Why not just allow/require each extension to
>> specify its name as a constant string?  We could force the matter by
>> redefining PG_MODULE_MAGIC as taking an argument:
>> PG_MODULE_MAGIC("hstore");

> We kind of already have something like this, for NLS.  If you look for 
> pg_bindtextdomain(TEXTDOMAIN) and ereport_domain(), this information 
> already trickles into the vicinity of the error data.  Maybe the same 
> thing could just be used for this, by wiring up the macros a bit 
> differently.

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
macro definition from some in-core extension.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: CREATE TABLE creates a composite type corresponding to the table row, which is and is not there
Следующее
От: Noah Misch
Дата:
Сообщение: Re: AIX support