[BUGS] BUG #8218: Error when querying an JSON data, 9.3beta
The following bug has been logged on the website:
Bug reference: 8218
Logged by: Daniel Zlatev
Email address: daniel.zla...@gmail.com
PostgreSQL version: Unsupported/Unknown
Operating system: Windows
Description:
Dears,
today I was playing with some JSON data, and I have noticed something
strange.
1. I've created the follwing table:
CREATE TABLE products (
data JSON
);
2. Then inserting some data:
INSERT INTO products(data) VALUES('{id: 1, name: shoes, in_stock:
5}');
INSERT INTO products(data) VALUES('[1,2,3,4,5]');
3. Then i've run this SELECT statement
SELECT * FROM products WHERE (data-'in_stock')::integer 0
Output was:
[Err] ERROR: cannot extract field from a non-object
I can understand the reason behind this error(JSON array don't has fields),
but for me it is very logical postgres to exclude this row from the
returning set, rather to throw an error.
So that is it.
Best regards
Daniel
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8218: Error when querying an JSON data, 9.3beta
daniel.zla...@gmail.com writes:
CREATE TABLE products (
data JSON
);
INSERT INTO products(data) VALUES('{id: 1, name: shoes, in_stock:
5}');
INSERT INTO products(data) VALUES('[1,2,3,4,5]');
SELECT * FROM products WHERE (data-'in_stock')::integer 0
Output was:
[Err] ERROR: cannot extract field from a non-object
I can understand the reason behind this error(JSON array don't has fields),
but for me it is very logical postgres to exclude this row from the
returning set, rather to throw an error.
Hm. In principle we could allow - to return NULL rather than failing
when there's no such field, but I'm not sure that would represent good
language design. However, this example definitely shows there are some
holes in the current set of JSON manipulation functions. The only way
to avoid a failure here would be to write something like
WHERE (CASE WHEN json_has_field(data, 'in_stock') THEN
(data-'in_stock')::integer ELSE NULL::integer END) 0
but there is no json_has_field test function, nor any nice way to
build one from the provided functions.
It's probably too late to address this for 9.3, but we ought to put it
on the to-do list for 9.4.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #8219: Windows installer fails when username contains spaces
The following bug has been logged on the website: Bug reference: 8219 Logged by: Matthew King Email address: matt7...@gmail.com PostgreSQL version: 9.2.4 Operating system: Windows 7 (64-bit) Description: I attempted to install PostgreSQL 9.2.4, but the installer failed with Invalid %COMSPEC%. I checked the installer log. It appears the reason for failure was that my username (Matt (2)) contains spaces. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8198: ROW() literals not supported in an IN clause
=?UTF-8?Q?Rafa=C5=82_Rzepecki?= divided.m...@gmail.com writes: I'm pretty sure the original intent was to afford some extra checks so that conditions such as ROW(1, 2) IN ((ROW(3, 4), ROW(5, 6, 7)) would get rejected at parsing time (CCing the original author; please confirm). No; the reason it was like that was that when that code was written, make_row_comparison_op was the only way to compare two row values at all. We didn't have record_eq and friends; nor did we have arrays of composites. Since the restriction seems a rather arbitrary (at least I fail to see any reason for it), it can be removed altogether (patch 0002, not tested as well): This is reasonable as far as it goes, but I think it doesn't go far enough --- there's really no reason anymore to reject RowExprs as components of ScalarArrayOpExpr either. I've extended this patch some and committed it. Thanks for the report! regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
