Re: Improving PL/Tcl's error context reports

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Improving PL/Tcl's error context reports
Date: 2024-07-04 15:27:43
Message-ID: 974c2531-536a-4223-a264-166872386459@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2024-07-04 15:37:48 Re: Problem while installing PostgreSQL using make
Previous Message torikoshia 2024-07-04 15:27:30 Add on_error and log_verbosity options to file_fdw