Re: Problems with variable cursorname in ecpg - Mailing list pgsql-hackers

From Boszormenyi Zoltan
Subject Re: Problems with variable cursorname in ecpg
Date
Msg-id 4BB30953.6050703@cybertec.at
Whole thread Raw
In response to Re: Problems with variable cursorname in ecpg  (Michael Meskes <meskes@postgresql.org>)
Responses ECPG pointer vs array
Re: Problems with variable cursorname in ecpg
Re: Problems with variable cursorname in ecpg
List pgsql-hackers
Michael Meskes írta:
>> The interpretation of the standard in the above way (DECLARE is declarative,
>> ...
>>     
>
> It's not just interpretation, but also a regression if we were to change this.
>   

Obviously.

>> The uniqueness problem can only be solved with modifying
>> the runtime library to keep track of the cursor names in the client.
>> It would ruin the declarative nature of DECLARE but would increase
>> compatibility with Informix, and we would also need to implement
>> correct "FREE cursorname" behaviour, too. Which would also bring
>> the consequence that the ECPG client library would need to
>> forbid cursors and prepared statements with the same name as
>> "FREE" can also free cursors and prepared statements.
>>     
>
> True.
>
>   
>> I think the current behaviour is the best we could achieve
>> while keeping close standard conformance.
>>     
>
> I think we should  make the error message/documentation a little bit clearer as
> people have stumbled over it.

Yes, we need to document it.

> Having said that couldn't we keep the statement
> declarative only for statements that do not carry a variable? This will not
> break any onld program and besides using a variable that doesn't exist, because
> you're outside a function doesn't make sense either.

I think you forget that in this case, only global variables are
usable in the DECLARE in this case, no local variables in
functions preceding the DECLARE are visible to it.

What we need here is an extra check in ECPGdump_a_type().
We need to raise an error if    ECPGdump_a_type(name, type, ...)
and   var = with find_variable(name);
on the passed name disagrees in the variable type and maybe
a warning if they disagree in the brace_level. The same applies
to the indicator variable. For that, we need to pass the brace_level
to ECPGdump_a_type() for both the variable and the indicator.

>  This is probably something
> for 9.1 though if it indeed works. 
>   

Best regards,
Zoltán Böszörményi

-- 
Bible has answers for everything. Proof:
"But let your communication be, Yea, yea; Nay, nay: for whatsoever is more
than these cometh of evil." (Matthew 5:37) - basics of digital technology.
"May your kingdom come" - superficial description of plate tectonics

----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
http://www.postgresql.at/



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: pending patch: Re: HS/SR and smart shutdown
Next
From: Boszormenyi Zoltan
Date:
Subject: ECPG pointer vs array