> It's probably pretty easy to add this, but I think the question is
> what would make it better than storing the same representation in a
> text field.
I completely agree. The main point in making a new datatype would be
to add support for operations that are normally done with graphs.
>Obviously you get validation that the input is in the
> correct format, but you could do that with a CHECK constraint, too, or
> otherwise handle it in the application. So I think the really
> interesting question is: what operations would you support on this
> data type?
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.
> One of the problems you're likely to run into if you store the whole
> graph as a single object is that it may make many of the things you
> want to do with it not very efficient.
Yes, I agree. On further thought, I believe it would be more of a pain
if we stick to representing the whole thing as one.Rather,making
multiple components will be more flexible and modular, and allow us to
modify different components of the same graph without modifying or
interfering with other components of the graph.
I will think of a new design. I am still thinking of using HStore to
store adjacency lists. This should have good performance for access of
lists and similar tasks, IMO.
Regards,
Atri
--
Regards,
Atri
*l'apprenant*
