Re: Throw error and ErrorContext question. - Mailing 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
>