Expose pc_point_(de)serialize and pc_patch_(de)serialize from libpc.a

[estebanzimanyi]

Need

Downstream extensions that build on top of pgPointCloud's C API (in our case MobilityDB, to add temporal point-cloud types) need to call the four entry points

• pc_point_serialize
• pc_point_deserialize
• pc_patch_serialize
• pc_patch_deserialize

against in-memory PCPOINT / PCPATCH values produced by libpc.a.

These four functions are already declared non-static and exposed via pc_api.h, but their definitions live in pgsql/pc_pgsql.c, which compiles into the PostgreSQL extension .so rather than into libpc.a. Linking them out of the PG extension is fragile (ELF symbol interposition, dual-load) and forces every downstream consumer to maintain a verbatim vendored copy, which is exactly the kind of drift libpc.a exists to prevent.

Question for the maintainers

Would you accept a small PR that makes these four entry points reachable from libpc.a, while preserving your existing code philosophy?

We see two minimal-change shapes and would like guidance on which (if either) you'd consider:

Option A — pure build change (smallest possible). Add a build rule that compiles the (de)serialize chain (the block currently at pgsql/pc_pgsql.c lines 508–964) into libpc.a as well. No code moves, no behavior change. The only catch is that the current chain calls palloc / SET_VARSIZE / BUFFERALIGN, so libpc.a would inherit a PG dependency it doesn't have today — which we suspect is precisely the line you don't want to cross.

Option B — relocate the chain into lib/ with PG-isms abstracted away. Move the four entry points (and the static helpers they need) into a new lib/pc_serialize.c. Replace:

• palloc → existing pcalloc
• SET_VARSIZE / VARSIZE → tiny inline helpers in lib/pc_api_internal.h that read/write the same 4-byte length prefix ((size << 2))
• BUFFERALIGN → one-line macro in lib

Move SERIALIZED_POINT / SERIALIZED_PATCH struct definitions to lib/pc_api.h (they're already accessed by name from lib/-side code paths via the public API). The PG extension keeps calling the same four public symbols, just resolved out of libpc.a instead of its own translation unit. No semantic change; ~250 LOC moved, ~30 LOC added.

We'd much rather match your preference than guess. If neither shape is acceptable in principle, we'd appreciate knowing that too so we can plan accordingly downstream.

Happy to send the PR once you point us at the shape you'd review.