Re: Throw error and ErrorContext question. - Mailing list pgsql-hackers
From | Gevik Babakhani |
---|---|
Subject | Re: Throw error and ErrorContext question. |
Date | |
Msg-id | 008e01c822fb$5d1e4660$0a01a8c0@gevmus Whole thread Raw |
In response to | Re: Throw error and ErrorContext question. (Tom Lane <tgl@sss.pgh.pa.us>) |
List | pgsql-hackers |
Hello Tom, I have a solution by adding two parameters (skip_error and skipped_sqlerrorcode) to qualifiedNameToVar,transformWholeRowRef,addImplicitRTE,warnAutoRange. It still needs a bit of refining before I can send the patch for full review. When in context of parsing functions for refname.colname: If refname is unknown, skip_error=true makes sure the error is skipped. I use skipped_sqlerrorcode to record what went wrong in qualifiedNameToVar and transformWholeRowRef. The effect is that de default behavior, including implicit RTE is kept. For example, when parsing the function below: 1. qualifiedNameToVar skips the error for the unknown refx and sets skipped_sqlerrorcode. 2. transformWholeRowRef also skips the error for the unknown refx and sets skipped_sqlerrorcode. 3. at this point the callabck also returns with error, because refx is not the function's name (myfunc) So I think an error like "missing FROM-clause entry for table "refx" would be appropriate here In normal circumstance qualifiedNameToVar would have reported the same. create function myfunc(par1 integer) $$ select refx.par1 from tbl1 a where a.field1 = 1; $$ language sql; I am working on all possible test scenarios I can think of to be sure the implementations is working correctly. Regards, Gevik. ------------------------------------------------ Gevik Babakhani PostgreSQL NL http://www.postgresql.nl TrueSoftware BV http://www.truesoftware.nl ------------------------------------------------ > -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > Sent: Thursday, November 08, 2007 2:32 AM > To: Gevik Babakhani > Cc: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Throw error and ErrorContext question. > > "Gevik Babakhani" <pgdev@xs4all.nl> writes: > > 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. > > Yeah, you'd throw the same error number and message as that > routine would have thrown, but matching that is not rocket > science ;-). > I don't see any value in trying to have only one instance of the > ereport() call instead of two --- it's going to cost you > *more* lines of code and *more* intellectual complexity to > try to trap and re-throw the error than it will cost to just > have two identical > ereport() calls. > > Although quite frankly I don't see any need to be touching > qualifiedNameToVar at all. It's already defined to return > NULL if it doesn't find the name anyplace in the query, which > seems to me to be what you want anyway. The only > non-internal error it might raise is "ambiguous name" which > is fine. That's an error condition, and the possibility that > there is a function variable visible at an outer name scoping > level doesn't make it not an error. > > The place where you need to be refactoring is probably in or > around the transformWholeRowRef/ParseFuncOrColumn sequence. > > One thing that we need to think about is what is the priority > of function-variable matching compared to implicit RTE > creation. I'm inclined to think we should allow function > variables to go first... > > regards, tom lane >
pgsql-hackers by date: