On 2019-06-22 22:00:12 +1200, William Denton wrote:
> >I guess the original question basically boils down to "Given a
> >rogue/dumb app, and a DBA who neglected his job, is it PG's
> >business (or even within its possibilities) to mop up ?"
>
> It feels like you aren't setting people up to land in the pit of success.
> It's easy to sit back and call people negligent because they failed to
> change settings from their defaults. Data breaches are all too common
> due to mis-configured systems, we can all have a good laugh at the
> poor people who have suffered breaches due to defaults that
> come/came with s3, mongo and many other data stores, but why must
> we operate on that level to rather than being a little more defensive?
>
> 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" and you can then search through a hundred million
rows of data to find that violation.
Useful error messages are one of reasons why I prefer Postgres over
Oracle.
Actually, I would like to get the input data which contributed to the
row which caused that error, but this is of course not trivial (there
are a few fascinating research papers about the topic).
> Is the client application supposed to parse that data?
Nope. The client application should show it to the user or log it
somewhere where an authorized person can find it. "Something didn't
work, please ask your system administrator" is not an adequate error
message if the system administrator has no way to get additional
information.
hp
--
_ | Peter J. Holzer | we build much bigger, better disasters now
|_|_) | | because we have much more sophisticated
| | | hjp@xxxxxx | management tools.
__/ | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
Attachment:
signature.asc
Description: PGP signature
