PL/pgSQL Todo, better information in errcontext from plpgsql

"Pavel Stehule" <pavel.stehule@hotmail.com> writes:

I miss some info in context: function's oid, function's argumenst and
schema. Maybe:

199292 function public.foo(int, int, int) language plpgsql statement return
line 10

Putting the OID there is a seriously awful idea, not least because it
would make it impossible to have stable regression-test outputs.

I'm not really convinced that we need more than the function name.

regards, tom lane

Hi, Tom,

Tom Lane wrote:

I miss some info in context: function's oid, function's argumenst and
schema. Maybe:

199292 function public.foo(int, int, int) language plpgsql statement return
line 10

Putting the OID there is a seriously awful idea, not least because it
would make it impossible to have stable regression-test outputs.

I'm not really convinced that we need more than the function name.

I also think that the OID will hurt here, but schema and argument types
may be useful in some corner cases.

Markus

--
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf. | Software Development GIS

Fight against software patents in Europe! www.ffii.org
www.nosoftwarepatents.org

"Pavel Stehule" <pavel.stehule@hotmail.com> writes:

I miss some info in context: function's oid, function's argumenst and
schema. Maybe:

199292 function public.foo(int, int, int) language plpgsql statement

return

line 10

Putting the OID there is a seriously awful idea, not least because it
would make it impossible to have stable regression-test outputs.

I'm not really convinced that we need more than the function name.

regards, tom lane

it's strong argument, but it's true. I didn't think about it. Without fid I
am not able identify function.

regards
Pavel Stehule

_________________________________________________________________
Chcete sdilet sve obrazky a hudbu s prateli? http://messenger.msn.cz/

Hi, Tom,

Tom Lane wrote:

I miss some info in context: function's oid, function's argumenst and
schema. Maybe:

199292 function public.foo(int, int, int) language plpgsql statement

return

line 10

Putting the OID there is a seriously awful idea, not least because it
would make it impossible to have stable regression-test outputs.

I'm not really convinced that we need more than the function name.

I also think that the OID will hurt here, but schema and argument types
may be useful in some corner cases.

And what two variants of errcontext drived by GUC? First current
(compatible) and second enhanced (with oid, params, maybe all possible debug
values) and possible machine's readable. This enhanced variant can be
compatible and shared in all environments.

Regards
Pavel Stehule

_________________________________________________________________
Emotikony a pozadi programu MSN Messenger ozivi vasi konverzaci.
http://messenger.msn.cz/

"Pavel Stehule" <pavel.stehule@hotmail.com> writes:

And what two variants of errcontext drived by GUC? First current
(compatible) and second enhanced (with oid, params, maybe all possible debug
values) and possible machine's readable. This enhanced variant can be
compatible and shared in all environments.

[ shrug... ] The complaints I've heard about the errcontext mechanism
are that it's too verbose already. I can't see a good use-case for the
above, and I do know that a lot of people wouldn't consider it an
"enhancement" at all.

I suspect the problems you wish to solve would be better addressed by
using the plpgsql debugger that will be available with 8.2. It sounds
to me like you are wishing for a debugger stack trace, and if you need
one of those you probably need other debugger facilities too.

regards, tom lane

"Pavel Stehule" <pavel.stehule@hotmail.com> writes:

And what two variants of errcontext drived by GUC? First current
(compatible) and second enhanced (with oid, params, maybe all possible

debug

values) and possible machine's readable. This enhanced variant can be
compatible and shared in all environments.

[ shrug... ] The complaints I've heard about the errcontext mechanism
are that it's too verbose already. I can't see a good use-case for the
above, and I do know that a lot of people wouldn't consider it an
"enhancement" at all.

I suspect the problems you wish to solve would be better addressed by
using the plpgsql debugger that will be available with 8.2. It sounds
to me like you are wishing for a debugger stack trace, and if you need
one of those you probably need other debugger facilities too.

plpgsql debugger's plugin can be solution. But it's big gun for me and has
little bit overhead. We have really large plpgsql library, where we very
often use overloading of functions, and I finding way for usefull error
handling, and I need collect all possible information about stack track.
Current format of stack track isn't really usefull. Only name, line and
statement are less. With func oid I can get all other info later, without
it, I need estimate which functions are in stack track. By example, for me
aren't important language, in 99% is plpgsql.

I wouldn't use debugger in production datatabase.

Pavel Stehule

_________________________________________________________________
Citite se osamele? Poznejte nekoho vyjmecneho diky Match.com.
http://www.msn.cz/

On Oct 5, 2006, at 9:30 AM, Pavel Stehule wrote:

With func oid I can get all other info later, without it, I need
estimate which functions are in stack track.

Why do you need the OID to know exactly what function something is?
What's wrong with schema.function(args)?
--
Jim Nasby jim@nasby.net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

--
Jim Nasby jimn@enterprisedb.com
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

On Oct 5, 2006, at 9:30 AM, Pavel Stehule wrote:

With func oid I can get all other info later, without it, I need estimate
which functions are in stack track.

Why do you need the OID to know exactly what function something is? What's
wrong with schema.function(args)?
--

oid is simply unique. I can take source code, args and all without parsing.
It's only one difference. I unlike parsing.

I don't think so regress tests needs showing errcontext now. Regress test
are in C and we can exactly set what we would show?

Regards
Pavel Stehule

_________________________________________________________________
Emotikony a pozadi programu MSN Messenger ozivi vasi konverzaci.
http://messenger.msn.cz/

"Pavel Stehule" <pavel.stehule@hotmail.com> writes:

Why do you need the OID to know exactly what function something is? What's
wrong with schema.function(args)?

oid is simply unique. I can take source code, args and all without parsing.
It's only one difference. I unlike parsing.

That isn't an adequate reason for pushing an implementation detail into
the user's face. IMHO no error message seen by ordinary users should
mention OIDs at all. A thought experiment: what would you do with the
message if we were to reimplement the system to not use OIDs?

I'm willing to talk about putting a complete specification of the
function (with schema and arg types) into the context line, but you
haven't really made the case why that wouldn't be just clutter for most
people.

regards, tom lane

On Oct 6, 2006, at 1:47 AM, Pavel Stehule wrote:

On Oct 5, 2006, at 9:30 AM, Pavel Stehule wrote:

With func oid I can get all other info later, without it, I need
estimate which functions are in stack track.

Why do you need the OID to know exactly what function something
is? What's wrong with schema.function(args)?
--

oid is simply unique. I can take source code, args and all without
parsing. It's only one difference. I unlike parsing.

decibel=# select 'pg_catalog.abstimelt
(abstime,abstime)'::regprocedure::oid;
oid
-----
253

--
Jim Nasby jimn@enterprisedb.com
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

Why do you need the OID to know exactly what function something is?
What's wrong with schema.function(args)?
--

oid is simply unique. I can take source code, args and all without
parsing. It's only one difference. I unlike parsing.

decibel=# select 'pg_catalog.abstimelt
(abstime,abstime)'::regprocedure::oid;
oid
-----
253

hmm, it changes situation. With it OID isn't really necessery. i didn't know
it before.

Regards
Pavel Stehule

_________________________________________________________________
Chcete sdilet sve obrazky a hudbu s prateli? http://messenger.msn.cz/