| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Peter Geoghegan <pg(at)heroku(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Wanted: jsonb on-disk representation documentation |
| Date: | 2014-05-07 19:27:37 |
| Message-ID: | 2918.1399490857@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
And while I'm looking at it ...
The jsonb_ops storage format for values is inherently lossy, because it
cannot distinguish the string values "n", "t", "f" from JSON null or
boolean true, false respectively; nor does it know the difference between
a number and a string containing digits. This appears to not quite be a
bug because the consistent functions force recheck for all queries that
care about values (as opposed to keys). But if it's documented anywhere
I don't see where. And in any case, is it a good idea? We could fairly
easily change things so that these cases are guaranteed distinguishable.
We're using an entire byte to convey one bit of information (key or
value); I'm inclined to redefine the flag byte so that it tells not just
that but which JSON datatype is involved.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2014-05-07 19:35:56 | Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers |
| Previous Message | Peter Geoghegan | 2014-05-07 19:27:15 | Re: Wanted: jsonb on-disk representation documentation |