Re: Typed hstore proposal

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:

> On 12/22/2011 10:44 AM, Tom Lane wrote:
>> "Johann 'Myrkraverk' Oskarsson"<johann(at)2ndquadrant(dot)com> writes:
>>> I mean to create a typed hstore, called tstore for now.
>> Um ... what is the point of this, exactly? From what I've seen,
>> most applications for hstore are pretty happy with the fact that
>> hstore is only weakly typed, and if an entry *is* an integer, or a
>> float, or whatever else, it's not hard to cast to and from text as
>> needed. So this idea looks like a solution in search of a problem,
>> which is going to need a whole lot more work before it even gets to
>> the point of being as useful as hstore. It's not for instance
>> apparent what is the use of iterating over only entries that were
>> supplied as integers --- there is no reason to think that they're
>> related just because of that.

No, which is why each( tstore ) returns the whole thing, as tvalues.

Also, it can be quite helpful in some cases to ask "what is the type
of this key" rather than cast to an integer and hope it works.

Typed in this case means each value is typed. There are (as yet) no
reason nor facility to add type constraints for a given key within the
implementation itself.

> Yeah, the thing that's annoying in some cases about hstore is not
> that it's untyped but that it's flat.

As I already pointed out (well, implied) is that it's trivial to allow
tstore to be recursive.

> That's what a JSON type would buy us, a lightweight tree structured
> type, and moreover one that is widely and increasingly used and well
> understood.

While I have not meant tstore to be a JSON type, it's not hard to make
it fully compatible with JSON by providing such input/output
functions.

Here it's noteworthy that I mean tstore to be richer than JSON. Some
type ideas:

* boolean

* bytea

* float4

* float8

* int2

* int4

* int8

* null (or some provision to have unvalued keys)

Not all of the above may be supported by the first implementation.
Notably bytea may be skipped.

And later on, possibly some subset or all of the time types:

* timestamp with time zone

* timestamp without time zone

* interval

* date

* time with time zone

* time without time zone

For JSON compatibility and tree structures:

* tstore (nested)

* tvalue arrays (or another way to have JSON compatible arrays)

It might also be worthwhile to have a specific JSON type, possibly
using the same underlying structure just with different input/output
functions.

--
Johann Oskarsson http://www.2ndquadrant.com/ |[]
PostgreSQL Development, 24x7 Support, Training and Services --+--
|
Blog: http://my.opera.com/myrkraverk/blog/