Re: Graph datatype addition

On Mon, Apr 29, 2013 at 10:12 PM, Misa Simic <misa.simic@gmail.com> wrote:
> Hi Atri,
>
> What is an example of custom internal representation and its JSON
> representation (though and JSON and HStore represent its value as text)?
>
> I also think  that the key question is:  "what operations would you support
> on this
> data type?"
>
> Or what kind of problems it will solve? (what can't be solved now - or can
> now - but new type will allow the better way...)
>
> Thanks,
>
> Misa
>
>

Hi Misa,

Thanks for thinking it through.

I have not thought about it yet(I was going with the HStore
representation till the moment, which I showed in my first mail in
this thread) I believe that something on these lines could be done:

Entity 1:

Node: Node1

Adjacency list: node2, node3, node4

Entity 2:

Node: Node 2

Adjacency list: node1, node5

Entity 3:

Node: Node 3

Adjacency list: node1, node4

Adjacency list sets:

"Node1"=>"Entity1","Node2"=>"Entity2","Node3"=>"Entity3"

I mentioned the potential operations we could have in a previous
mail.Specifically,

I can think of the standard tasks, i.e. searching if two nodes are
connected or not,adding new nodes and edges, traversing the adjacency
lists of nodes.

If we add support for weighted graphs, we can probably add support for
some common graph algorithms, such as Djikstra's algorithm, Bellman
Ford algorithm, a MST making algorithm, network flow algorithms.

The main idea is to allow user to work with graphs pretty easily, and
allow the user to use the data present in his database to make graphs
and then process them.

I think we find work arounds or make shifts at the moment if we need
to use graphs in our database in postgres. If we have a datatype
itself, with support for commonly used operations built inside the
type itself, that will greatly simplify user's tasks, and open up a
whole new avenue of applications for us, such as recommender systems,
social network analysis, or anything that can be done with graphs.