On Sun, Jan 13, 2019 at 9:30 AM Tom Lane <t...@sss.pgh.pa.us> 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 assume it can copy Datum values using > datumCopy() or equivalent logic. More often than not, such copying > is done to move the value into a different memory context in preparation > for freeing the original context. If you delete the GraphBLAS object > when the original context is deleted, you now have a dangling pointer > in the copy. > > We did invent some infrastructure awhile ago that could potentially > handle this sort of situation: it's the "expanded datum" stuff. > The idea here would be that your representation involving a GraphBLAS > pointer would be an efficient-to-operate-on expanded object. You > would need to be able to serialize and deserialize that representation > into plain self-contained Datums (probably varlena blobs), but hopefully > GraphBLAS is capable of going along with that. You'd still need a > memory context reset callback attached to each expanded object, to > free the associated GraphBLAS object --- but expanded objects are > explicitly aware of which context they're in, so at least in principle > that should work. (I'm not sure anyone's actually tried to build > an expanded-object representation that has external resources, so > we might find there are some bugs to fix there.) > > Take a look at > > src/include/utils/expandeddatum.h > src/backend/utils/adt/expandeddatum.c > src/backend/utils/adt/array_expanded.c > src/backend/utils/adt/expandedrecord.c > > Ah I see, the water is much deeper here. Thanks for the detailed explanation, expandeddatum.h was very helpful and I see now how array_expanded works. If I run into any problems registering my callback in the expanded context I'll repost back.
Thanks Tom! -Michel > regards, tom lane >
