From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | 德哥 <digoal(at)126(dot)com>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #14463: refcursor cann't used with array or variadic parameter? |
Date: | 2016-12-13 21:37:38 |
Message-ID: | 775.1481665058@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
I wrote:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
>> It is not a bug - it is feature. PLpgSQL statements doesn't expect a
>> expression on some places.
> Well, it's not unreasonable to expect that a subscripted datum could
> be used. It looks to me like this is a grammar omission and the
> executor code would work fine.
Well, not so much. I was thinking in terms of unifying both
getdiag_target and cursor_variable with the assign_var production, but
actually pl_exec.c is only on board with doing that for getdiag_target.
However, we can get it to throw a more sensible error by seeing whether
the next token is '['. I'm not that concerned about whether you can
use an array element in OPEN, but the current error message certainly
looks like a bug rather than an omitted feature.
I've pushed a patch that fixes the error message and also allows
the case for GET DIAGNOSTICS.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | digoal | 2016-12-14 02:56:53 | BUG #14465: cursor for insert into select ... returning cann't streaming fetch? |
Previous Message | David G. Johnston | 2016-12-13 19:52:11 | Re: BUG #14464: Problems about FUNCTIONS |