Re: Opening a plpgsql cursor parameter by name - Mailing list pgsql-hackers

From Yeb Havinga
Subject Re: Opening a plpgsql cursor parameter by name
Date
Msg-id 4C9A6425.2070509@gmail.com
Whole thread Raw
In response to Re: Opening a plpgsql cursor parameter by name  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: Configuring synchronous bikeshedding
Next
From: David Fetter
Date:
Subject: Another Modest Proposal: Platforms