Re: Opening a plpgsql cursor parameter by name

Поиск
Список
Период
Сортировка
От Yeb Havinga
Тема Re: Opening a plpgsql cursor parameter by name
Дата
Msg-id 4C9A6425.2070509@gmail.com
обсуждение исходный текст
Ответ на Re: Opening a plpgsql cursor parameter by name  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tom Lane wrote:
> Yeb Havinga <yebhavinga@gmail.com> writes:
>   
>> We intend to implement $subject, so instead of mycursor CURSOR (myparm text) IS SELECT myparm; OPEN mycursor('A');
itwould be possible to do OPEN mycursor(myparm := 'A');
 
>>     
>
> Is this really worth the trouble?  Is it supported by any other DBMS?
> Are cursors used so much, or with so many parameters, that there's a
> real benefit to be gained?  (I tend to think that FOR loops are better
> than cursors 99% of the time.)
>   
Thanks for your reply.

For us it is worth the trouble. We must either implement this, or 
manually rewrite cursor use in 140K lines of PL code to be migrated from 
another DBMS, where cursors are used more with named parameters calling 
than positional. The code contains both the OPEN mycursor(myparm => 'A') 
syntax as well as FOR rec IN mycursor(myparm => 'A') LOOP ... (but not 
FOR rec IN SELECT .. LOOP)).
> I wouldn't be so obstructionist if this syntax weren't in flux.
> But seeing that we have hopes of migrating from := to => before
> very long, adding another dependency on that choice where it's
> not buying a lot of functionality doesn't seem like a good idea.
>   
So maybe it's a good idea that we use the => syntax and do not submit 
the patch before the := to => migration is done.

regards,
Yeb Havinga




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

Предыдущее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: Configuring synchronous bikeshedding
Следующее
От: David Fetter
Дата:
Сообщение: Another Modest Proposal: Platforms