Re: skipping context for RAISE statements - maybe obsolete?

Pavel Stehule <pavel.stehule@gmail.com> writes:
> Some flag of RAISE statement can be solution, but I don't like it.
> Probably you would to change behave for all RAISE statements in
> function - not individually for one or second. And when you debug some
> application, you probably invite any solution that ensure change
> without necessity to modify function's source code. I know so GUC are
> limited, but in this cases, it has a minimal impact to data - and it
> can be ajusted on database, session, function level.

I think this is entirely wrong.  The use-case for suppressing the
context lines is where you have a "user facing" RAISE message, as
opposed to an "internal" failure where you want the context to help you
debug why the failure happened.  IMO there is no reason whatever to
suppose that all or none of the RAISEs in a particular function are
user-facing cases.  A mixture of internal errors and user-facing errors
is certainly common enough in our backend code, why would it be
different for plpgsql functions?

The argument that a GUC would require less application code change is
equally nonsense, since you'd have to add SET clauses to each function
to determine the behavior.  The only way you'd not end up doing that is
if an *entire application* had only user-facing or only internal errors,
which doesn't seem like a likely scenario at all.

Another point is that if you decorated only some of your functions with
SET clauses, you'd end up with action-at-a-distance with the behavior of
individual RAISEs in undecorated functions depending on the call path.
This seems unlikely to work pleasantly.

> A analogy is our
> solution for SQL identifiers and plpgsql variables solving collisions
> - it is best, and I newer heard about any issue.

I don't find that to be a relevant precedent at all.  For one thing,
there's nothing corresponding to the idea that some RAISEs might want
one behavior and some another even within the same function.  I also
note that we did provide a non-GUC way of dealing with that problem;
the GUC way was meant as a quick stopgap for people who'd not yet
looked at their issues more closely.
        regards, tom lane