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

From Tom Lane
Subject Re: Improving PL/Tcl's error context reports
Date
Msg-id 26372.1720114586@sss.pgh.pa.us
Whole thread Raw
In response to Re: Improving PL/Tcl's error context reports  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: Improving PL/Tcl's error context reports
List pgsql-hackers
Pavel Stehule <pavel.stehule@gmail.com> writes:
> čt 4. 7. 2024 v 17:27 odesílatel Heikki Linnakangas <hlinnaka@iki.fi>
> napsal:
>> What happens if you rename a function? I guess the error context will
>> still print the old name, but that's pretty harmless.

> The rename should to generate different tid, so the function will be
> recompiled

Right.  With patch:

regression=# create function bogus() returns int language pltcl as
'return [expr 1 / 0]';
CREATE FUNCTION
regression=# select bogus();
ERROR:  divide by zero
CONTEXT:  while executing
"expr 1 / 0"
    (procedure "__PLTcl_proc_bogus" line 2)
    invoked from within
"__PLTcl_proc_bogus"
in PL/Tcl function "bogus"
regression=# alter function bogus() rename to stillbogus;
ALTER FUNCTION
regression=# select stillbogus();
ERROR:  divide by zero
CONTEXT:  while executing
"expr 1 / 0"
    (procedure "__PLTcl_proc_stillbogus" line 2)
    invoked from within
"__PLTcl_proc_stillbogus"
in PL/Tcl function "stillbogus"

>> 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.

If the namespace depends on the OID then we still have nonreproducible
stack traces, no?  We could maybe make Tcl namespaces that match the
SQL schema names, but that doesn't get us out of the duplication
problem when there are similarly-named functions with different
argument lists.

Another idea is to make the Tcl names include the SQL schema name,
that is __PLTcl_proc_myschema_myfunction.  That avoids needing to
append OIDs when the problem is functions in different schemas,
but it doesn't move the needle for overloaded functions.  On the
whole I feel like that'd add verbosity without buying much.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Improving PL/Tcl's error context reports
Next
From: Pavel Stehule
Date:
Subject: Re: Improving PL/Tcl's error context reports