Re: Problems with variable cursorname in ecpg

Поиск
Список
Период
Сортировка
От Boszormenyi Zoltan
Тема Re: Problems with variable cursorname in ecpg
Дата
Msg-id 4BB30953.6050703@cybertec.at
обсуждение исходный текст
Ответ на Re: Problems with variable cursorname in ecpg  (Michael Meskes <meskes@postgresql.org>)
Ответы ECPG pointer vs array  (Boszormenyi Zoltan <zb@cybertec.at>)
Re: Problems with variable cursorname in ecpg  (Michael Meskes <meskes@postgresql.org>)
Re: Problems with variable cursorname in ecpg  (Boszormenyi Zoltan <zb@cybertec.at>)
Список 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 по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: pending patch: Re: HS/SR and smart shutdown
Следующее
От: Boszormenyi Zoltan
Дата:
Сообщение: ECPG pointer vs array