> 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* -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
