Re: PL/pgSQL, RAISE and error context - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: PL/pgSQL, RAISE and error context
Date
Msg-id CAFj8pRDc==LOPxXDYS82igCA0-NvCysVc_yOMqQvsssThyHsZw@mail.gmail.com
Whole thread Raw
In response to Re: PL/pgSQL, RAISE and error context  (Marko Tiikkaja <marko@joh.to>)
Responses Re: PL/pgSQL, RAISE and error context
List pgsql-hackers


2015-01-26 13:39 GMT+01:00 Marko Tiikkaja <marko@joh.to>:
On 1/26/15 1:14 PM, Pavel Stehule wrote:
2015-01-26 13:02 GMT+01:00 Marko Tiikkaja <marko@joh.to>:
I can see where it's a lot nicer not to have the context visible for
people who only care about the contents of the message, but the way it's
done in PL/PgSQL right now is just not good enough.  On the other hand, the
backwards compatibility breakage of doing this in libpq is quite
extensive.  The most simple option seems to be to just allow a GUC to
change PL/PgSQL's behavior to match what all other PLs are doing.


libpq was changed more time - there is still a open task about a protocol
change.

I afraid about some unexpected side effects of your proposal if somebody
mix languages - these side effects should not be critical

I have no idea what you're talking about.  What kind of side effects?

what will be a error context if plpgsql calls a plperl function that raises a exception
what will be a error context if plperl calls a plpgsql functions that raises a exception

- but on second
hand current behave is not critical too - we can wait.

I think the current behavior is almost unacceptable.  It makes debugging in some cases really, really difficult.

if it is necessary, then we can modify libpq

Regards

Pavel

 


.marko

pgsql-hackers by date:

Previous
From: Marko Tiikkaja
Date:
Subject: Re: PL/pgSQL, RAISE and error context
Next
From: Sawada Masahiko
Date:
Subject: fix typo in guc.c