Allowing same cursor name in nested levels

Поиск
Список
Период
Сортировка
От Jeevan Chalke
Тема Allowing same cursor name in nested levels
Дата
Msg-id CAM2+6=VJfhEoxG4hrYp40n4vzUhQLCJhh6vswWKZX4YuNn6R2w@mail.gmail.com
обсуждение исходный текст
Ответы Re: Allowing same cursor name in nested levels  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hi Tom,

While going through few test-cases, I found that we cannot have two opened cursors with same name even though they are in two different functions. Here is what I mean:

1. I have two functions func1 and func2.
2. func1 calls func2
3. Both has cursor with same name, say mycursor
4. Somehow I forgot closing it
5. executing func1 throws an error 'cursor "mycursor" already in use'


Is this expected behavior???

I just mingled around the code and later appended a cursor count to the cursor name to allow same cursor name in nested levels. I have run make check and didn't find any side-effect other than one expected output change.

PFA, patch for the same.

Please let me know your views / suggestions.

Thanks

Test-case:
===

CREATE OR REPLACE FUNCTION func1() RETURNS void AS $$
DECLARE
 res int;
 mycursor CURSOR FOR SELECT 'foo';
BEGIN
 OPEN mycursor;
 SELECT func2() INTO res;
END;
$$ LANGUAGE plpgsql;

CREATE OR REPLACE FUNCTION func2() RETURNS int AS $$
DECLARE
 mycursor CURSOR FOR SELECT 'bar';
BEGIN
 OPEN mycursor;
 return 1;
END;
$$ LANGUAGE plpgsql;

SELECT func1();
ERROR:  cursor "mycursor" already in use
CONTEXT:  PL/pgSQL function "func2" line 5 at OPEN
SQL statement "SELECT func2()"
PL/pgSQL function "func1" line 7 at SQL statement




--
Jeevan B Chalke
Senior Software Engineer, R&D
EnterpriseDB Corporation
The Enterprise PostgreSQL Company

Phone: +91 20 30589500

Website: www.enterprisedb.com
EnterpriseDB Blog: http://blogs.enterprisedb.com/
Follow us on Twitter: http://www.twitter.com/enterprisedb

This e-mail message (and any attachment) is intended for the use of the individual or entity to whom it is addressed. This message contains information from EnterpriseDB Corporation that may be privileged, confidential, or exempt from disclosure under applicable law. If you are not the intended recipient or authorized to receive this for the intended recipient, any use, dissemination, distribution, retention, archiving, or copying of this communication is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and delete this message.
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: Re: Should we have an optional limit on the recursion depth of recursive CTEs?
Следующее
От: Dimitri Fontaine
Дата:
Сообщение: Re: some missing internationalization in pg_basebackup