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

From Julien Rouhaud
Subject Re: Adding the extension name to EData / log_line_prefix
Date
Msg-id pcicxvh23yvw5ys4g5iuqpku26cv6hjau5tgepvjqkx45zwoh5@brttsdclx6gt
Whole thread Raw
In response to Re: Adding the extension name to EData / log_line_prefix  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, May 13, 2024 at 07:11:53PM GMT, Tom Lane wrote:
> 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");

FTR there was a proposal at [1] some time ago that could be used for that need
(and others), I thought it could be good to mention it just in case.  That
would obviously only work if all extensions uses that framework.

[1] https://www.postgresql.org/message-id/flat/3207907.AWbSqkKDnR%40aivenronan



pgsql-hackers by date:

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