Thank you, Aleksander and Tom!
I ended up using JSONB instead of a custom datatype. The actual work involves an iCal extension written in C. I'm not fluent in C or PostgreSQL internals. The iCal library stores pointers in its struct, and serializing and saving that caused the first seg fault because the pointer was no longer valid. Then I tried the custom datatype using varlena and encountered a type-casting issue. That led me to realize my custom datatype used offsets for each part of the iCal properties and stored this in the varlena header. However, when PostgreSQL processes this binary data, it arranges it in the most efficient order, making the offsets in the header point to the wrong data.
Regards,
Thomas
Hi Aleksander and Tom,
Thank you for your help.
I ended up using JSONB instead of a custom data type. The actual work involves an iCal extension written in C. I'm not fluent in C or PostgreSQL internals, which led to a few challenges.
Initially, I encountered a segmentation fault because the iCal library stores pointers in its struct, and serializing and saving that caused the pointer to become invalid.
Then, when I tried to implement a custom data type using `varlena`, I ran into a type-casting issue. This made me realize that my custom data type was using offsets for each part of the iCal properties and storing these in the `varlena` header. However, when PostgreSQL processes this binary data, it rearranges it for efficiency, causing the offsets in the header to point to the wrong data.
Regards,
Thomas
Thomas Thai <thomas.t.thai@gmail.com> writes:
> PostgreSQL 18 beta crashes with a segmentation fault when casting strings
> to custom types. The crash occurs specifically in PostgreSQL's type-casting
> system, not in extension code.
The reason you're having a problem is that this is not a valid way to
store a custom type. The representation has to be a single blob of
memory [1], and it has to be represented in a way that lets
type-independent code determine its length. Typically that means
following the varlena-header rules.
regards, tom lane
[1] Well, there is a notion of an "expanded" representation that
doesn't have to be a flat blob. But you're not following the
rules for that either.
