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
>
