| From: | Atri Sharma <atri(dot)jiit(at)gmail(dot)com> |
|---|---|
| To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, PgHacker <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Graph datatype addition |
| Date: | 2013-04-29 14:25:11 |
| Message-ID: | CAOeZVif1funfFesvahT-JocBuKU=-CsX+CfbHYUziaw6qXuTOQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>
> This is an interesting idea. Historically I've always decomposed
> graphs into relational structures because that's the only practical
> way to query them. Graphs are not currently able to be transported
> out of the database currently via JSON so one of the areas to focus
> your research will be how the client will consume the data.
> libpqtypes is one way to do it, but that will really restrict you
> audience so you'll probably need a rich set of functions present the
> internal data (just like hstore).
I completely agree. Initially, I was thinking of exposing the data to
user via HStore. But now, after Robert's suggestions, I think it will
be better to have an alternate representation. JSON seems to be an
excellent idea for that.
I am thinking of having the functions for working on the graph present
inside the data type itself.
> Another area to focus research will be on searchability: how to use
> GIST/GIN indexes to pull data out via an internal query string. An
> overview of the current GIST based type implementations (like ltree)
I will definitely research that. Actually, I have never looked at
GIST/GIN code before, so I have no idea how they can be used here.
Regards,
Atri
--
Regards,
Atri
l'apprenant
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Merlin Moncure | 2013-04-29 14:50:45 | Re: Graph datatype addition |
| Previous Message | Tom Lane | 2013-04-29 14:01:41 | Re: Functional dependencies and GROUP BY - for subqueries |