Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Would it be possible to store (and query) date/time values as well?

I have a use case where either HStore or JSONB might be neat (The most basic requirement is K/V, so HStore might be good enough. I could use nested structures as well though). Unfortunately some of the values I need to store are datetime values and I'd need to query based on those:

"Give me all documents where the datetime is from this year"

The article claims HStore is basically just strings (might work for bool as well, but not numbers/datetimes). JSON can express strings, numbers, booleans - but not datetime values.

Has anyone done something similar? Is that even possible?



why not make the date values a real column? does it need to be inside the JSON?


The use case I'm looking at is a legacy application that allows you to define various 'dynamic' fields. Think document, extracted data and you can expose fieldA, fieldB and fieldC, while another user wants D, E and F.

Right now that application stores that in a rather messy way. Exposing this as a table field would mean that configuration changes (New field/a different field) causes a structural change (alter table). Or you have to go down the 'Date1, Date2, Date3, Number1, Number2' ... path.

In short: I see no way to expose these pieces of information in fields without ugly hacks, hence my interest in HStore/JSON(B) - but datetime based filters would be quite nice to have..


Re datetime filters:

If the datetimes are ISO formatted strings, would regex matching not work for basic filtering?

    where json_field.datetime similar to '2016-07-.*'
Of course, it'll probably be slow-tastic, and less convenient than native datetime manipulation, but hey, maybe it's enough to get unblocked?


You can use an expression index, which casts to timestamptz, would then be very fast to query and filter on such.


why not do both?


One thing you'll run into is that json doesn't have a datetime type so you're left with using either a number of seconds since 1970 (fairly standard) or a string representation [1].

With either approach you'll have to do some mapping in and out of the system (though date probably serialises to string more or less out of the box for most json libs).

[1] http://stackoverflow.com/questions/10286204/the-right-json-d...


I mentioned the limitation ("no datetime in json") in my post :-)

That said, you and IanCal have a point: I could just drop the idea of DateTimes and use timestamps/integers - converting queries in my application.


Ah, yeah, sorry about that... I don't think I'd had my coffee!


Can you store the times as timestamps? You can query on things being in an integer range then.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: