Re: [HACKERS] PL/pgSQL Todo, better information in errcontext from plpgsql
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/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] PL/pgSQL Todo, better information in errcontext from plpgsql
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/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] PL/pgSQL Todo, better information in errcontext from plpgsql
Pavel Stehule [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] PL/pgSQL Todo, better information in errcontext from plpgsql
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[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] PL/pgSQL Todo, better information in errcontext from plpgsql
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/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] PL/pgSQL Todo, better information in errcontext from plpgsql
Pavel Stehule [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] PL/pgSQL Todo, better information in errcontext from plpgsql
Pavel Stehule [EMAIL PROTECTED] 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/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] PL/pgSQL Todo, better information in errcontext from plpgsql
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[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) -- Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] PL/pgSQL Todo, better information in errcontext from plpgsql
Hello, 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 or short version: 1229298 function public.foo 10 return which is easy parseable Best regards Pavel Stehule _ Citite se osamele? Poznejte nekoho vyjmecneho diky Match.com. http://www.msn.cz/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] PL/pgSQL Todo, better information in errcontext from plpgsql
Pavel Stehule [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PL/pgSQL Todo, better information in errcontext from
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 TrackingTracing International AG Dipl. Inf. | Software Development GIS Fight against software patents in Europe! www.ffii.org www.nosoftwarepatents.org signature.asc Description: OpenPGP digital signature
Re: [HACKERS] PL/pgSQL Todo, better information in errcontext from plpgsql
Pavel Stehule [EMAIL PROTECTED] 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/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
