On 20/10/10 13:12, Darren Duncan wrote: > Never mind JSON. You can fix the outer joins problem and other issues > simply by supporting relation-valued attributes, or in other words, row > field values that are rowsets. You can for trees/forests yes. How would you handle more general graphs with cycles or bidirectional relationships, where you still want to be able to reconstruct them into a traversible graph client-side? There are existing graph databases for this, of course, but I've frequently wished to be able to use the power of SQL's query language and reporting facilities with my data as well as being able to extract it as (sub)graphs when needed. Using a graph database would usually cost me ACID, full SQL support, and in most cases all those goodies like triggers, constraints, etc as well. I think there's a real use case for using regular relational storage with a few SQL extensions to support returning graph-style rather than row-set style results. Even the SQL extensions probably aren't necesary; I suspect a (limited and somewhat slow) version could be done purely in a PL under PostgreSQL, and I've been thinking about trying to prototype one. > And recursively. Parent records in > outer rowset, child records inside. And this is all perfectly normal > for the relational model, and SQL's differing from this is part of how > SQL is crippled and not really the relational model. I demonstrate how > it might be better done with my Muldis D language. -- Darren Duncan You'd really wow people if you could bang together a working JPA 2.0 backend for that, or a dialect for an existing provider like Hibernate. Personally, I'd love to give someting like your Muldis-D query interface a go if it could live within PostgreSQL as a contrib module, using the regular Pg storage and just providing an alternative query facility. Right now, it looks like it is a perl-all-the-way system, with no interfaces for other languages and its own database storage system. In its current form a quick glance at the docs doesn't demonstrate any obvious advantage of using it over any of the existing well-established graph databases or object-relational database systems. -- Craig Ringer Tech-related writing: http://soapyfrogs.blogspot.com/ -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
