Michel Pelletier writes:
> It mentions "on disk" does this mean the flattened representation must be
> binary compatible with what matrix_send emits? They will likely be the
> same now, so I can see this as a convenience, but is it a requirement?
No, your on-the-wire representation for send/recv
After absorbing some of the code you've pointed out I have a couple of
questions about my understanding before I start hacking on making expanded
matrices.
Serializing sparse matrices can be done with _expand/_build functions, and
the size is known, so I can implement the EOM_flatten_into_methods.
On Sun, Jan 13, 2019 at 9:30 AM Tom Lane wrote:
> I suppose what you're doing is returning a pointer to a GraphBLAS object
> as a Datum (or part of a pass-by-ref Datum)? If so, that's not going
> to work terribly well, because it ignores the problem that datatype-
> independent code is going to
Michel Pelletier writes:
> This is no doubt the most complex bit of C wrapper I've done for postgres,
> and I've run into a bit of a snag. GraphBLAS objects are opaque handles
> that have their own new/free functions. After reading mmgr/README I have
> registered a callback with CurrentMemoryCon
Hello,
I'm working on an extension to wrap the GraphBLAS linear algebra package.
GraphBLAS provides a very flexible API over adjacency matrices for solving
graph problems. I've got Matrix and Vector types wrapped, build
aggregators and extraction functions to pivot tables into matrices and
back,
