Thread: User defined types and storage variance

User defined types and storage variance

From
Dave Trombley
Date:
    Is it correct of me to assume that the concrete storage of a user
defined type, defined in C, must not contain any references to
structures allocated per-object?  The documentation does not explicitly
specify this, but there is a lack of a callback in the CREATE TYPE
command to be invoked when the database type instance is no longer
referenced, so I see no way of freeing such storage if it were
allocated.  Also, I can't see how the backend would know how to follow
such a reference without some indication that it was a reference, and
also the storage length of the structure.  So this seems plain.

    What I'd like to do is implement a structure whose concrete storage
length may change when it is operated on (a sparse matrix), but since
realloc() on most systems may change the memory location of the pointer,
I see no way of doing this given the above restriction.  Perhaps it
would be possible to have a function somehow tell the back end to
associate the OID of the type instance it is operating on with a
different concrete storage block?

    More generally, exactly how /does/ concrete storage allocation and
deallocation behave for user-defined types?


    -David J. Trombley
     <dtrom@bumba.net>


Re: User defined types and storage variance

From
Tom Lane
Date:
Dave Trombley <dtrom@bumba.net> writes:
>     Is it correct of me to assume that the concrete storage of a user
> defined type, defined in C, must not contain any references to
> structures allocated per-object?

The concrete storage has to be a flat chunk of memory --- no pointers,
nothing that can't survive being moved around.  You don't get to control
moving, copying, or deleting.

            regards, tom lane