Alvaro Herrera writes:
> Tom Lane wrote:
>> So the wording would have to be "there is no label "foo" attached to
>> any block or loop enclosing this statement". That's a tad verbose,
>> but at least it's clear ...
> This seems good to me, verbosity notwithstanding.
Hearing no objections, I'll g
Tom Lane wrote:
> So the wording would have to be "there is no label "foo" attached to
> any block or loop enclosing this statement". That's a tad verbose,
> but at least it's clear ...
This seems good to me, verbosity notwithstanding.
--
Álvaro Herrerahttp://www.2ndQuadrant.co
I wrote:
> Hmm ... what do you think of wording the error as "there is no label "foo"
> attached to any block enclosing this statement"? That still leaves the
> terminology "block" undefined, but it seems better than "any statement
> enclosing this statement".
Actually, looking at the plpgsql doc
Jim Nasby writes:
> On 8/22/15 2:53 PM, Tom Lane wrote:
>> ... Given the way the namespace data
>> structure works, I am not sure that we can realistically detect at line 8
>> that there was an instance of lab1 earlier, but perhaps we could word the
> Are there any other reasons we'd want to impr
On 8/25/15 10:50 AM, Jim Nasby wrote:
figuring out the cause of his problem. Given the way the namespace data
structure works, I am not sure that we can realistically detect at line 8
that there was an instance of lab1 earlier, but perhaps we could word the
Are there any other reasons we'd wan
On 8/22/15 2:53 PM, Tom Lane wrote:
This message seems confusing: label "lab1" does exist, it's just not
attached to the right loop. In a larger function that might not be too
obvious, and I can easily imagine somebody wasting some time before
Agreed.
figuring out the cause of his problem.
I had a few second thoughts about the wording of the error messages
in this area.
First, consider
create or replace function foo() returns void language plpgsql as $$
begin
<>
loop
exit lab1; -- ok
end loop;
loop
exit lab1; -- not so ok
end loop;
end$$;
ERROR: label "lab1" d
On 8/21/15 7:21 PM, Tom Lane wrote:
Applied with some fixes. The major oversight was that EXIT does*not*
have the same rules as CONTINUE, as is clearly documented (though in your
defense, there was no regression test verifying the behavior ... there is
now).
Yay more tests.
>I refactored the
Jim Nasby writes:
> On 8/17/15 9:48 AM, Tom Lane wrote:
>>> I'm inclined to think that if we wanted to make this better, the way to
>>> improve it would be to detect the error*at compile time*, and get rid of
>>> this hack in plpgsql_exec_function altogether.
> Here's a patch that does that. This
On 8/17/15 4:46 PM, Tom Lane wrote:
Jim Nasby writes:
On 8/17/15 9:48 AM, Tom Lane wrote:
I'm inclined to think that if we wanted to make this better, the way to
improve it would be to detect the error*at compile time*, and get rid of
this hack in plpgsql_exec_function altogether.
So split
Pavel Stehule writes:
> when I implemented this check in plpgsql_check I found another minor issue
> in CONTINUE statement - the typename is wrong
Hmmm ... a bit of nosing around says that fetch/move and get diagnostics
are similarly sloppy. Will fix.
regards, tom lane
Hi
2015-08-17 23:46 GMT+02:00 Tom Lane :
> Jim Nasby writes:
> > On 8/17/15 9:48 AM, Tom Lane wrote:
> >> I'm inclined to think that if we wanted to make this better, the way to
> >> improve it would be to detect the error*at compile time*, and get rid of
> >> this hack in plpgsql_exec_function
Jim Nasby writes:
> On 8/17/15 9:48 AM, Tom Lane wrote:
>> I'm inclined to think that if we wanted to make this better, the way to
>> improve it would be to detect the error*at compile time*, and get rid of
>> this hack in plpgsql_exec_function altogether.
> So split PLPGSQL_NSTYPE_LABEL into PLP
On 8/17/15 9:48 AM, Tom Lane wrote:
I'm inclined to think that if we wanted to make this better, the way to
improve it would be to detect the error*at compile time*, and get rid of
this hack in plpgsql_exec_function altogether. pl_gram.y already
successfully detects cases where CONTINUE mentions
Jim Nasby writes:
> Calling CONTINUE with a label that's not a loop produces an error
> message with no context info [1].
True.
> I think err_stmt should probably only be reset in the non-return case a
> bit below that. I'm not sure about err_text though.
That is not going to help, as you'd s
2015-08-17 6:19 GMT+02:00 Jim Nasby :
> Calling CONTINUE with a label that's not a loop produces an error message
> with no context info [1]. This is because of
>
> rc = exec_stmt_block(&estate, func->action);
> if (rc != PLPGSQL_RC_RETURN)
> {
> estate.err_
Calling CONTINUE with a label that's not a loop produces an error
message with no context info [1]. This is because of
rc = exec_stmt_block(&estate, func->action);
if (rc != PLPGSQL_RC_RETURN)
{
estate.err_stmt = NULL;
estate.err_text = NUL
17 matches
Mail list logo
