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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] 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" <[EMAIL PROTECTED]> 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 > ---------------------------(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
