| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | tomas(at)tuxteam(dot)de |
| Cc: | Gregory Stark <stark(at)enterprisedb(dot)com>, Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: My honours project - databases using dynamically attached entity-properties |
| Date: | 2007-03-16 13:56:23 |
| Message-ID: | 45FAA207.30401@dunslane.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
tomas(at)tuxteam(dot)de wrote:
>
>> Does hstore nest? My impression is that it doesn't. Which might well not
>> matter, of course.
>>
>
> If what you mean is to have "mappings of mappings" then no.
>
> Hstore implements a data type for a (finite) mapping (a set of key -> value
> pairs, think "hash" for perl folks), with operations like "H1 contains
> H2" (in the sense that all key-value pairs in H2 are also in H1)
> supported by an index. Keys and values are strings.
>
>
As a perl folk I think of hashes as nestable :-). Unlike hstore, the
keys are strings but the values can be anything, including a hashref or
arrayref.
Anyway, this means that you can't use hstore to cover the same field as
YAML or JSON. That doesn't mean it's not useful - far from it.
cheers
andrew
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2007-03-16 14:37:34 | Re: UPDATE using sub selects |
| Previous Message | Robert Treat | 2007-03-16 13:37:13 | Re: tsearch_core for inclusion |