On Wed, May 8, 2013 at 2:16 PM, Atri Sharma 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 pot
>
> 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
> cha
On 5/8/13 1:40 PM, Atri Sharma wrote:
On Thu, May 2, 2013 at 7:58 AM, Atri Sharma wrote:
Sent from my iPad
On 02-May-2013, at 4:33, Misa Simic wrote:
On Wednesday, May 1, 2013, Atri Sharma wrote:
Hi all,
Please find a probable prototype for the same:
struct GraphNode
{
Oid NodeO
On Thu, May 2, 2013 at 7:58 AM, Atri Sharma wrote:
>
>
> Sent from my iPad
>
> On 02-May-2013, at 4:33, Misa Simic wrote:
>
>
>
> On Wednesday, May 1, 2013, Atri Sharma wrote:
>>
>> Hi all,
>>
>> Please find a probable prototype for the same:
>>
>> struct GraphNode
>> {
>> Oid NodeOid;//
Sent from my iPad
On 02-May-2013, at 4:33, Misa Simic wrote:
>
>
> On Wednesday, May 1, 2013, Atri Sharma wrote:
>> Hi all,
>>
>> Please find a probable prototype for the same:
>>
>> struct GraphNode
>> {
>> Oid NodeOid;// Oid of the row which is the node here. We will
>> store an
On Wednesday, May 1, 2013, Atri Sharma wrote:
> Hi all,
>
> Please find a probable prototype for the same:
>
> struct GraphNode
> {
> Oid NodeOid;// Oid of the row which is the node here. We will
> store an identifier to it here rather than the complete row(with data)
> itself.
> Adjac
Hi all,
Please find a probable prototype for the same:
struct GraphNode
{
Oid NodeOid;// Oid of the row which is the node here. We will
store an identifier to it here rather than the complete row(with data)
itself.
AdjacencyList *list; // Pointer to the node's adjacency list.
};
st
> actually, i was going to suggest to Atri to take a look at that,
> pgrouting is currently in develop of v2.0 which will rewrite some
> parts (including some of the algorithms).
>
> Maybe this datatype could fit better as part of pgrouting
Thanks, I will have a look at pgRouting.Although, in a sh
> 1. We created JSON and XML types as ways of storing data that has a robust
> validation system.
>
> They're still, in a sense, just "plain old text", but it's "plain old text"
> that the user can be certain satisfies the respective rules for
> representations.
Yes, although, I feel that we can
> I believe it would be best to largely separate the questions of storage and
> access. Partly because of Florian's concern that you'd frequently want only
> one representation of the whole graph, but also because the actual storage
> interface does NOT have to be user friendly if we have a good ac
> Have you considered maybe ltree datatype?
>
> To me all described sounds solveable on pure sql way ( + ltree datatype to
> help with indexes and performance as materialised path to avoid recursive
> query all the time...)
This may build over the existing solutions itself. I will have to check th
> Usually though, you'd be interested a large graphs which include
> information for lots of records (e.g., nodes are individual users,
> or products, or whatever). A graph datatype is not well suited for
> that, because it'd store each graph as a single value, and updating
> the graph would mean r
On Mon, Apr 29, 2013 at 10:51 PM, Peter Eisentraut wrote:
> On Sun, 2013-04-28 at 22:55 -0700, Atri Sharma wrote:
>> 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 algorit
On Sun, 2013-04-28 at 22:55 -0700, Atri Sharma wrote:
> 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.
You might find that pgRouting alr
On 30/04/13 12:33, Любен Каравелов wrote:
- Цитат от Christopher Browne (cbbro...@gmail.com), на 29.04.2013 в 23:18
-
The one place where I *could* see a special type having a contribution
is for there to be a data type that can contain an arbitrary number of
links. That means you have
- Цитат от Christopher Browne (cbbro...@gmail.com), на 29.04.2013 в 23:18
-
>
> The one place where I *could* see a special type having a contribution
> is for there to be a data type that can contain an arbitrary number of
> links. That means you have one tuple per node, and, instead o
On Mon, Apr 29, 2013 at 10:50 AM, Merlin Moncure wrote:
> On Mon, Apr 29, 2013 at 9:25 AM, Atri Sharma wrote:
> >>
> >> This is an interesting idea. Historically I've always decomposed
> >> graphs into relational structures because that's the only practical
> >> way to query them. Graphs are
On 4/29/13 2:20 PM, Florian Pflug wrote:
On Apr29, 2013, at 21:00 , Atri Sharma wrote:
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 it
On Monday, April 29, 2013, Atri Sharma wrote:
> On Mon, Apr 29, 2013 at 10:12 PM, Misa Simic
> >
> 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
On Apr29, 2013, at 21:00 , Atri Sharma wrote:
> 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 use
On Mon, Apr 29, 2013 at 10:12 PM, Misa Simic 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
Hi Merlin,
" Graphs are not currently able to be transported
out of the database currently via JSON"
What does it mean?
(I probably dont understand graphs well - but from my point of view - any
data can be transported out of DB via JSON)
Thanks,
Misa
2013/4/29 Merlin Moncure
> On Mon, Apr
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
>
> I don't agree with this; JSON is not really designed to store graphs.
> You will probably need a customized internal representation, just like
> hstore, that expresses a graph like structure.
Yes, we will have a custom internal representation. I was thinking of
ways to export the graph into us
On Mon, Apr 29, 2013 at 9:25 AM, Atri Sharma wrote:
>>
>> This is an interesting idea. Historically I've always decomposed
>> graphs into relational structures because that's the only practical
>> way to query them. Graphs are not currently able to be transported
>> out of the database currentl
>
> This is an interesting idea. Historically I've always decomposed
> graphs into relational structures because that's the only practical
> way to query them. Graphs are not currently able to be transported
> out of the database currently via JSON so one of the areas to focus
> your research wi
On Mon, Apr 29, 2013 at 12:55 AM, Atri Sharma wrote:
>> 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
> 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.
>Obvious
On Sun, Apr 28, 2013 at 1:06 AM, Atri Sharma wrote:
> Inspired by the awesome work done by Oleg sir in HStore, I have been thinking
> about making a graph data type as an extension in postgres.
>
> I have been reading about graph databases and how storing data in graphs can
> lead to some really
Hi all,
Inspired by the awesome work done by Oleg sir in HStore, I have been thinking
about making a graph data type as an extension in postgres.
I have been reading about graph databases and how storing data in graphs can
lead to some really awesome functionalities such as social network analy
30 matches
Mail list logo
