Re: [REVIEW] Patch for cursor calling with named parameters

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Royce Ausburn <royce.ml@inomial.com>, Pg Hackers <pgsql-hackers@postgresql.org>, yebhavinga@gmail.com
Date: 2011-10-06T16:38:21Z
Lists: pgsql-hackers
On Thu, Oct 6, 2011 at 12:23 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Royce Ausburn <royce.ml@inomial.com> writes:
>> Initial Review for patch:
>> http://archives.postgresql.org/pgsql-hackers/2011-09/msg00744.php
>> The patch adds a means of specifying named  cursor parameter arguments in pg/plsql.
>
>>       • Do we want that?
>
>> I very rarely use pg/plsql, so I won't speak to its utility.  However there has been some discussion about the idea:
>> http://archives.postgresql.org/pgsql-hackers/2010-09/msg01440.php
>
> I still think what I said in that message, which is that it's premature
> to add this syntax to plpgsql cursors when we have thoughts of changing
> it.  There is not any groundswell of demand from the field for named
> parameters to cursors, so I think we can just leave this in abeyance
> until the function case has settled.

+1.  However, if that's the route we're traveling down, I think we had
better go ahead and remove the one remaining => operator from hstore
in 9.2:

CREATE OPERATOR => (
        LEFTARG = text,
        RIGHTARG = text,
        PROCEDURE = hstore
);

We've been warning that this operator name was deprecated since 9.0,
so it's probably about time to take the next step, if we want to have
a chance of getting this sorted out in finite time.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company