Re: Improving PL/Tcl's error context reports
От | Pavel Stehule |
---|---|
Тема | Re: Improving PL/Tcl's error context reports |
Дата | |
Msg-id | CAFj8pRD4fCxsRGoV3z73cefPoE4GU-W4ORaVK5VNVTpw3PyjKg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Improving PL/Tcl's error context reports (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Improving PL/Tcl's error context reports
|
Список | pgsql-hackers |
čt 4. 7. 2024 v 19:36 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
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.
I like the idea of using a schema name inside. It doesn't fix all, but the cost can be low, and some risk of duplicity is reduced.
Getting unique name based on suffix _oid looks not too much nice (using _increment can be nicer), but it should to work
PLpgSQL uses more often function signature
(2024-07-04 19:49:20) postgres=# select bx(0);
ERROR: division by zero
CONTEXT: PL/pgSQL function fx(integer) line 1 at RETURN
PL/pgSQL function bx(integer) line 1 at RETURN
ERROR: division by zero
CONTEXT: PL/pgSQL function fx(integer) line 1 at RETURN
PL/pgSQL function bx(integer) line 1 at RETURN
What can be interesting information
How much work can be using modified function signature for internal name like
__PLTcl_proc_myschema_myfunction_integer
__PLTcl_trigger_myschema_myfunction_table_schema_table
Is there some size limit for variable name? I didn't find it.
regards, tom lane
В списке pgsql-hackers по дате отправления: