Those are the internals we currently expose as unsafe “sys” bindings.
As we/contributors identify more that are desired we add them.
pgrx’ focus is on providing safe wrappers and general interfaces to the Postgres internals, which is the bulk of our work and is what will take many years.
As unsafe bindings go, we could just expose everything, and likely eventually will. There’s just some practical management concerns around doing that without a better namespace organization —- something we’ve been working.
The Postgres sources are not small. They are very complex, inconsistent in places, and often follow patterns that are specific to Postgres and not easy to generalize.
If you’ve never built an extension with pgrx, give it a shot one afternoon. It’s very exciting to see your own code running in your database.
Those are the internals we currently expose as unsafe “sys” bindings.
As we/contributors identify more that are desired we add them.
pgrx’ focus is on providing safe wrappers and general interfaces to the Postgres internals, which is the bulk of our work and is what will take many years.
As unsafe bindings go, we could just expose everything, and likely eventually will. There’s just some practical management concerns around doing that without a better namespace organization —- something we’ve been working.
The Postgres sources are not small. They are very complex, inconsistent in places, and often follow patterns that are specific to Postgres and not easy to generalize.
If you’ve never built an extension with pgrx, give it a shot one afternoon. It’s very exciting to see your own code running in your database.