Jim Nasby <Jim.Nasby@BlueTreble.com> 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 improve the ns stuff? Doesn't
> seem worth it for just this case, but if there were other nitpicks
> elsewhere maybe it is.
I'm not aware offhand of any other cases where it's not getting the job
done.
>> error message to cover either possibility. Maybe something like "there is
>> no label "foo" surrounding this statement"?
> "surrounding" seems pretty nebulous. Maybe "no label "foo" in this
> context"? I'd say we use the term block, but we differentiate between
> blocks and loops. Perhaps it would be best to document namespaces and
> make it clear that blocks and loops both use them. :/
I agree that "surrounding" might not be the best word, but it seems more
concrete than "in this context". The point is that the label needs to be
attached to a block/loop that contains the CONTINUE/EXIT statement.
I considered phrasing it as "no label that contains this statement", but
thinking of the label itself as containing anything seemed pretty bogus.
> Regardless of that, a hint is probably warranted. "Is "foo" a label for
> an adjacent block or loop?"?
Meh. Doesn't do anything for me. If we had positive detection, we could
add an errdetail saying "There is a label "foo", but it's not attached to
a block that encloses this statement.". But without being able to say
that for sure, I think the hint would probably just be confusing.
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".
regards, tom lane
