On 05/07/2014 02:52 PM, Andres Freund wrote:
> On 2014-05-07 14:48:51 -0400, Tom Lane wrote:
>> Andres Freund <andres@anarazel.de> writes:
>>> * The jentry representation should be changed so it's possible to get the type
>>> of a entry without checking individual types. That'll make code like
>>> findJsonbValueFromSuperHeader() (well, whatever you've renamed it to)
>>> much easier to read. Preferrably so it an have the same values (after
>>> shifting/masking) ask the JBE variants. And it needs space for futher
>>> types (or representations thereof).
>> Further types? What further types? JSON seems unlikely to grow any
>> other value types than what it's got.
> I am not thinking about user level exposed types, but e.g. a hash/object
> representation that allows duplicated keys and keeps the original
> order. Because I am pretty sure that'll come.
>
That makes one of you. We've had hstore for years and nobody that I
recall has asked for preservation of key order or duplicates. And any
app that relies on either in JSON is still, IMNSHO, broken by design.
OTOH, there are suggestions of "superjson" types that support other
scalar types such as timestamps.
cheers
andrew
