On 11/07/2014 11:17 AM, Andrew Dunstan wrote:
On 11/07/2014 10:51 AM, Ross Reedstrom wrote:
This is a serious bug in 9.3.5 and 9.4 beta3:
row_to_json() yields empty strings for json keys if the data is
fulfilled by an index only scan.
Example:
testjson=# select count(*) from document_acl;
count
-------
426
(1 row)
testjson=# SELECT row_to_json(combined_rows) FROM (
SELECT uuid, user_id AS uid, permission
FROM document_acl_text AS acl
WHERE uuid = '8f774048-8936-4d7f-aa38-1974c91bbef2'
ORDER BY user_id ASC, permission ASC
) as combined_rows;
row_to_json
---------------------------------------------------------------------
{"":"8f774048-8936-4d7f-aa38-1974c91bbef2","":"admin","":"publish"}
That seems odd. Here's what the relevant code does:
td = DatumGetHeapTupleHeader(composite);
/* Extract rowtype info and find a tupdesc */
tupType = HeapTupleHeaderGetTypeId(td);
tupTypmod = HeapTupleHeaderGetTypMod(td);
tupdesc = lookup_rowtype_tupdesc(tupType, tupTypmod);
...
for (i = 0; i < tupdesc->natts; i++)
...
attname = NameStr(tupdesc->attrs[i]->attname);
escape_json(result, attname);
Could this be a bug in lookup_rowtype_tupdesc()?
Further data point:
There's nothing json-specific about this, BTW:
andrew=# select hstore(q) from (select * from idxo order by a) q;
hstore
---------
""=>"1"
(1 row)
andrew=# set enable_seqscan = true;
SET
andrew=# select hstore(q) from (select * from idxo order by a) q;
hstore
------------------------------
"a"=>"1", "b"=>"b", "c"=>"c"
(1 row)
So it looks like the index scan only stuff is broken somewhere.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
