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 872748.1715641913@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
Re: Adding the extension name to EData / log_line_prefix
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2024-05-13 19:25:11 -0300, Fabrízio de Royes Mello wrote:
>> Hmmm, depending on the extension it can extensively call/use postgres code
>> so would be nice if we can differentiate if the code is called from
>> Postgres itself or from an extension.

> I think that's not realistically possible. It's also very fuzzy what that'd
> mean. If there's a planner hook and then the query executes normally, what do
> you report for an execution time error? And even the simpler case - should use
> of pg_stat_statements cause everything within to be logged as a
> pg_stat_statement message?

Not to mention that there could be more than one extension on the call
stack.  I think tying this statically to the ereport call site is
fine.

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");

            regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Adding the extension name to EData / log_line_prefix
Next
From: David Rowley
Date:
Subject: Re: Why is parula failing?