Skip site navigation (1) Skip section navigation (2)

Re: Problems with variable cursorname in ecpg

From: Boszormenyi Zoltan <zb(at)cybertec(dot)at>
To: Michael Meskes <meskes(at)postgresql(dot)org>
Cc: PostgreSQL Hacker <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Problems with variable cursorname in ecpg
Date: 2010-03-31 08:35:31
Message-ID: 4BB30953.6050703@cybertec.at (view raw or flat)
Thread:
Lists: 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/


In response to

Responses

pgsql-hackers by date

Next:From: Boszormenyi ZoltanDate: 2010-03-31 08:37:13
Subject: ECPG pointer vs array
Previous:From: Simon RiggsDate: 2010-03-31 08:00:38
Subject: Re: pending patch: Re: HS/SR and smart shutdown

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group