Jim Nasby <jim.na...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers