pgrx

(NB: Post author here!) This is all true! We have a bit more info on that choice in this post [1]. But in general the Toolkit extension [2] is meant to have a bit of a lighter touch than the core TimescaleDB extension [3], it's meant for moving faster and working almost entirely with the custom functions/types/operators type approach rather than the core extension which is integrated much more deeply into the planner & executor and deals with a number of other hooks. It would be possible to do that in Rust, but because it's so deeply integrated with the main Postgres codebase there would just be a lot of translation going on and you'd get a lot less of the benefits of working in Rust. So C is more natural for much of the core DB extension. PGX [4] is also a huge help for writing this sort of extension. The point of Toolkit is really to m

Regarding deep copies, have you considered writing it as a plugin in something like rust? https://github.com/zombodb/pgx

I think the existing int64, microsecond-precision timestamptz type is a good compromise of space and performance for precision for many use cases. Indeed, there are use cases where greater precision is desired. One of the features of PostgreSQL I appreciate is the ability to extend its types. There are a number of type extensions available. See https://pgxn.org for a list of popular extensions. I don't know of an existing nanosecond-precision timestamptz type, but it's not that much of a lift to create one yourself. I've muddled through C a couple of times to do so. Often I pick an existing extension that's similar to what I want to do, and modify it. And if Rust is more to your liking, there's a toolkit for building extensions in Rust as well: https://github.com/zombodb/pgx A drawback of using custom extensions is you're often limited to