Shay Rojansky writes:
>> I don't think that's true - schema information (table, column names)
>> definitely seems like it's in a different category than table contents.
>
> You're not visualizing this with the appropriate amount of paranoia: just
> because the database thinks that something is a
On 2019-06-22 19:09:41 +0200, Karsten Hilbert wrote:
> 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
> >
On 6/22/19 10:09 AM, Karsten Hilbert wrote:
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. Othe
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
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
On 6/22/19 6:00 AM, 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 s
>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 neg
On Thu, Jun 20, 2019 at 12:16:53PM -0400, Tom Lane wrote:
> Admittedly, in your example there's a difference between what "the app"
> should know and what "the user using the app" should know. But I'm not
> really seeing how Postgres could usefully model that situation. We have
> no idea about t
"David G. Johnston" writes:
> Just to be clear here, the OP provided the following query example:
> test=# update person set email = null;
> ERROR: null value in column "email" violates not-null constraint
> DETAIL: Failing row contains (william, denton, null).
> The presence of william and de
On Thu, Jun 20, 2019 at 9:17 AM Tom Lane wrote:
> Karsten Hilbert writes:
> > Sure, but we are currently exploring whether the database
> > reflects any values that it had not been given by the same
> > user beforehand.
>
> > There might be another scenario:
> > user enters value for colum
> More generally: I find this complaint a little confusing. We did not
> consider reporting the "show row contents" DETAIL to the client to be a
> security hazard when it was added, because one would think that that's
> just data that the client already knows anyway. I'd be interested to see
> a
Shay Rojansky writes:
>> Yeah, it's fairly hard to see how we could respond to this complaint
>> without lobotomizing our error messages to the point of near uselessness.
>> Almost any non-constant text in an error report could possibly be seen
>> as hazardous.
> I don't think that's true - schem
Karsten Hilbert writes:
> Sure, but we are currently exploring whether the database
> reflects any values that it had not been given by the same
> user beforehand.
> There might be another scenario:
> user enters value for column 1
> app adds in secret-to-the-user value for column 2
>
>> A specifig knob for "sensitive data" cannot be supplied by
>> PostgreSQL because it cannot know beforehand what information
>> will be considered sensitive under a given, future, usage
>> scenario.
> Yeah, it's fairly hard to see how we could respond to this complaint
> without lobotomizing our
On Thu, Jun 20, 2019 at 05:22:20PM +0200, Shay Rojansky wrote:
> It seems generally agreed that all data from the database should be
> considered potentially sensitive and should therefore not be leaked in log
> messages - unless an explicit, informed opt-in is done. It is extremely
> easy to imag
Karsten,
>> In other words, this isn't about verbosity, but about sensitive data. It
>> seems like a specific knob for sensitive information may be required,
which
>> would be off by default and would potentially affect other fields as well
>> (if relevant).
>
> A specifig knob for "sensitive dat
Karsten Hilbert writes:
> On Thu, Jun 20, 2019 at 01:26:23PM +0200, Shay Rojansky wrote:
>> In other words, this isn't about verbosity, but about sensitive data. It
>> seems like a specific knob for sensitive information may be required, which
>> would be off by default and would potentially affec
On 6/20/19 4:26 AM, Shay Rojansky wrote:
Shay here, maintainer of the Npgsql driver for .NET.
>> Is there a setting where i can disable the DETAIL field being populated
>> with row data?
>
> See:
>
>
https://www.postgresql.org/docs/11/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-WHA
On Thu, Jun 20, 2019 at 01:26:23PM +0200, Shay Rojansky wrote:
> In other words, this isn't about verbosity, but about sensitive data. It
> seems like a specific knob for sensitive information may be required, which
> would be off by default and would potentially affect other fields as well
> (if
Shay here, maintainer of the Npgsql driver for .NET.
>> Is there a setting where i can disable the DETAIL field being populated
>> with row data?
>
> See:
>
>
https://www.postgresql.org/docs/11/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-WHAT
>
> log_error_verbosity
While this is helpful,
On 6/19/19 8:56 PM, William Denton wrote:
When inserting up updating a row with not null constraints that are not
satisfied, postgres reflects the values in the row in the error DETAIL.
postgres=# create database test;
CREATE DATABASE
postgres=# \c test;
psql (11.1 (Debian 11.1-3.pgdg90+1), ser
When inserting up updating a row with not null constraints that are not
satisfied, postgres reflects the values in the row in the error DETAIL.
postgres=# create database test;
CREATE DATABASE
postgres=# \c test;
psql (11.1 (Debian 11.1-3.pgdg90+1), server 11.2)
You are now connected to database "
22 matches
Mail list logo
