Re: enhanced error fields

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Peter Geoghegan <peter(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Subject: Re: enhanced error fields
Date: 2012-12-28 19:23:28
Message-ID: CAFj8pRBeZN=boOy+-h76p3CcwDbmmDZ+3OTMC_xCEqsc5pR4sg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2012/12/28 Peter Geoghegan <peter(at)2ndquadrant(dot)com>:
> On 28 December 2012 18:40, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>> If
>> I understand you, we have a fields that has behave that you expected -
>> filename and funcname. And I have not used these fields for
>> application programming.
>
> No, that's not what I mean. What I mean is that it seems questionable
> to want to do anything *within* an exception handler on the basis of
> where an exception was raised from. You should just place exception
> handlers more carefully instead.
>
> Are you aware of any popular programming language that provides this
> kind of information? Can you tell in a well-principled way what
> function a Python exception originated from, for example? These are
> the built-in Python 2 exception classes:
>
> http://docs.python.org/2/library/exceptions.html
>

for this subject ANSI SQL is more relevant source or manual for DB2 or
Oracle. Design of Python and native PL languages are different. Python
can use complex nested structures. PL - PL/pgSQL or PL/PSM is designed
for work with simply scalar types. So these environments are not
comparable.

> None of the Python built-in exception types have this kind of
> information available from fields or anything. Now, you might say that
> Python isn't Postgres, and you'd be right. I'm fairly confident that
> you'll find no precedent for a routine_name field in any code that is
> even roughly analogous to the elog infrastructure, though, because
> acting on the basis of what particular function the exception was
> raised from seems quite hazardous - it breaks any kind of
> encapsulation that might have existed.
>
> If one person slightly refactors their code, it could break the code
> of another person who has never even met or talked to the first.

yes, it is not valid argument, I am sorry. Lot of error fields doesn't
work if developer doesn't respect some coding standards. It is not
just routine_name. Only when your implementation is correct, then code
works.

Best regards

Pavel

>
> --
> Peter Geoghegan http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training and Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2012-12-28 19:33:37 Re: enhanced error fields
Previous Message Peter Geoghegan 2012-12-28 19:03:14 Re: enhanced error fields