On Wed, May 8, 2013 at 2:16 PM, Atri Sharma <atri.j...@gmail.com> wrote: >> >> Your second drawing didn't really make any sense to me. :( >> >> I do think it would be most productive to focus on what the API for dealing >> with graph data would look like before trying to handle the storage aspect. >> The storage is potentially dirt-simple, as others have shown. The only >> challenge would be efficiency, but it's impossible to discuss efficiency >> without some clue of how the data will be accessed. Frankly, for the first >> round of this I think it would be best if the storage really was just some >> raw tables. Once something is available people will start figuring out how >> to use it, and where the API needs to be improved. >> >> -- > > Thanks for your reply. > > Yes,my drawing sucks.heh. > > Ok,I agree. I was pretty perked up about efficiency in storage, hence > started designing.
This is the wrong place to start. A proposed API will help people understand the use cases you're trying to solve (if any) that are insufficiently covered by existing paradigms. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
