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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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