Re: Throw error and ErrorContext question.

Thank you Tom.

I have considered a noError boolean too.

but please considered the following:

step 1: call qualifiedNameToVar(noError = true), which generates an error 
but gets suppressed by noError parameter.

step 2: process function parameter name for 
funct1.param1, check "funct1" == <the name of the current function>,
which "funct1" is unknown/ambiguous (the name of the current function was
"func" for example).

In the case above I thought I somehow re-throw the error that
was originally generated at step 1.
Regards,
Gevik.

------------------------------------------------
Gevik Babakhani

PostgreSQL NL       http://www.postgresql.nl
TrueSoftware BV     http://www.truesoftware.nl
------------------------------------------------

> -----Original Message-----
> From: pgsql-hackers-owner@postgresql.org 
> [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Tom Lane
> Sent: Thursday, November 08, 2007 12:25 AM
> To: Gevik Babakhani
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Throw error and ErrorContext question. 
> 
> "Gevik Babakhani" <pgdev@xs4all.nl> writes:
> > I am trying to catch and copy an error to be re-thrown later.
> 
> This is certainly not the right way to go about solving your problem.
> If you need to refactor some of the column lookup routines to 
> make this patch work, then do so, but don't try to make an 
> already-thrown error not be an error.  (One good reason for 
> that is that you don't really know what error you are 
> catching --- it might be a report of some low-level problem 
> such as out-of-memory, for instance.)
> 
> The pattern you might want to follow is adding a noError 
> boolean parameter to functions you want to be able to get 
> failure returns back from.
> 
>             regards, tom lane
> 
> ---------------------------(end of 
> broadcast)---------------------------
> TIP 6: explain analyze is your friend
>