Christian Kruse-4 wrote
> Hi,
>
> On 10/03/14 14:09, David Johnston wrote:
>
>> The system supposes that, at a structural level, you are dealing with
>> column-consistent data and so if you ask for something that does not make
>> sense (i.e., an object key when you have an array or a scalar) it will
>> warn
>> you.
>
> Looking at the common usage of JSON it doesn't seem to be a good idea
> to imply column-consistent JSON. Normally when JSON is used the
> application ensures consistency and when a non-existent key is
> accessed NULL is returned. I think this is expected behavior and we
> should do it like that, too; if one wants it different, he should use
> CHECK constraints.
The database is the application. It's job is to store data so that,
multiple, other applications can access it and in such a way that those
applications do not have to enforce data integrity since the database has
taken care of that responsibility.
I can see it both ways and so maybe a set of null-returning functions and
operators need to be made standard so the user can choose which behavior is
desired. I cannot see changing the behavior of the current operators since
these are in the wild - though turning errors into non-errors isn't really a
risk since no existing code can reasonably be said to rely on such behavior.
The advantage of avoiding data-specific errors is probably worth it. It
makes finding problems harder, not easier, to locate if one doesn't make
liberal use of check constraints but personally I'd rather have some wrong
data interspersed with the good data instead of throwing out al the data
because one single value is bad - a value that may never make it to the
final result anyway.
David J.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/BUG-9519-Allows-storing-scalar-json-but-fails-when-querying-tp5795417p5795536.html
Sent from the PostgreSQL - bugs mailing list archive at Nabble.com.
