2012/12/11 Tom Lane <tgl@sss.pgh.pa.us>:
> 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.
I don't understand - I can set flags for related function via ALTER
FUNCTION and I don't need to change source code. I can do it as DBA
with DBA tools.
>
> 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.
we can enhance RAISE with flags WITHOUT CONTEXT or some similar, but
default behave should be same for custom and internal exceptions...
Current behave is little bit strange for somebody who doesn't know
postgresql internals. He can see context sometimes and sometimes not.
>
>> 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.
ok,
so are you thinking so current behave ok and it doesn't need change?
Regards
Pavel
>
> regards, tom lane