RRULE type cannot be stored

[Natureshadow]

Storing RRULEs in their compiled form leads to segmentation faults upon retrieval. This happens due to the icalrecurrencetype having an icaltimetype field, which in turn has a pointer to icaltimezone:

https://github.com/Marketcircle/libical/blob/4272d2f81851a37bb08d9ac977a2f672b54e2a20/src/libical/icaltime.h#L136

For obvious reasons, structs with pointers cannot be safely stored in Postgres heap files.

I don't know of any way to prevent a type from being stored, but maybe this should be documented with a huge red flag.

[thomastthai]

What about using a custom storage format for RRULEs to address the struct with pointer issues, like:

• Protocol Buffers (Protobuf)
• FlatBuffers
• Cap'n Proto

For example, some highlights (thanks AI) for how Protocol Buffers provides a workaround:

• Schema Definition: You define the structure of icalrecurrencetype in a .proto file without using pointers. Instead, you'll replace the icaltimezone pointer with a suitable time zone identifier (like a string representing the time zone name or ID).
• Serialization: When you serialize the structure, Protocol Buffers generates a compact binary format that does not include any pointers. This format is safe for storage in a PostgreSQL database. The binary data generated from this serialization can then be stored in a bytea field in PostgreSQL, safely avoiding the issues related to storing memory pointers, e.g., storing timezone_id as a string "America/New_York" instead of a pointer.
• Deserialization: When you retrieve the binary data from the database, Protobuf will deserialize it back into the original structure, ensuring that the timezone_id is properly retrieved as a string.
• Time Zone Rehydration: After deserialization, you can use the timezone_id (retrieved from the serialized data) to look up the appropriate icaltimezone object in memory (if needed). This prevents any issues with dangling pointers or segmentation faults, as the time zone data is always dynamically reloaded.