Re: Improving PL/Tcl's error context reports - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Improving PL/Tcl's error context reports
Date
Msg-id 974c2531-536a-4223-a264-166872386459@iki.fi
Whole thread Raw
In response to Improving PL/Tcl's error context reports  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Improving PL/Tcl's error context reports
Re: Improving PL/Tcl's error context reports
List pgsql-hackers
On 05/06/2024 20:42, Tom Lane wrote:
> While working on commit b631d0149, I got a bee in my bonnet about
> how unfriendly PL/Tcl's error CONTEXT reports are:
> 
> * The context reports expose PL/Tcl's internal names for the Tcl
> procedures it creates, which'd be fine if those names were readable.
> But actually they're something like "__PLTcl_proc_NNNN", where NNNN
> is the function OID.  Not only is that unintelligible, but because
> the OIDs aren't stable this forces us to disable display of the
> CONTEXT lines in all of PL/Tcl's regression tests.
> 
> * The first line of the context report (almost?) always duplicates
> the primary error message, which is redundant and not per our
> normal reporting style.
> 
> So attached is a patch that attempts to improve this situation.
> 
> The key question is how to avoid including function OIDs in the
> strings that will appear in the regression test outputs.  The
> answer I propose is to start with an internal name like
> "__PLTcl_proc_NAME", where NAME is the function's normal SQL name,
> and then append the OID only if that function name is not unique.
> As long as we don't create test cases that involve throwing
> errors from duplicatively-named functions, we can show the context
> reports and still have stable regression outputs.  I think this will
> improve the user experience for regular users too.

Yes, that sounds a lot nicer.

What happens if you rename a function? I guess the error context will 
still print the old name, but that's pretty harmless.

Hmm, could we do something with tcl namespaces to allow having two 
procedures with the same name? E.g. create a separate namespace, based 
on the OID, for each procedure. I wonder how the stack trace would look 
like then.

-- 
Heikki Linnakangas
Neon (https://neon.tech)




pgsql-hackers by date:

Previous
From: torikoshia
Date:
Subject: Add on_error and log_verbosity options to file_fdw
Next
From: Tom Lane
Date:
Subject: Re: Problem while installing PostgreSQL using make