On Sat, Jun 22, 2019 at 06:40:10PM +0200, Peter J. Holzer wrote:
> > How is it useful in a normally configured database to return row data in
> > error messages?
>
> This is extremely useful. It tells you what data didn't match your
> program's expectations. Otherwise you just get a vague "unique
> constraint violation"
Sure, except some argue that PG not send such information to
the *client* by *default*, which seems to have some merit
(the default should, however, keep logging such data to the
PG log)
This can lead to the following problem:
> and you can then search through a hundred million
> rows of data to find that violation.
which could be solved by passing to the client an identifier
instead of the row data which is also logged to the server
log alongside the row data. The combination of
%m or %n - timestamp
%c - session ID
%l - in-session log line idx
%e - SQLSTATE
would probably suffice if sent to the client, given it is
logged in the server log.
(not that I suggest any such thing as I certainly lack the
skills to provide a patch)
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B