From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | 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-13 23:11:53 |
Message-ID: | 872748.1715641913@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2024-05-13 23:24:53 | Re: Why is parula failing? |
Previous Message | Andres Freund | 2024-05-13 23:02:01 | Re: Adding the extension name to EData / log_line_prefix |