xataio / pgzx Goto Github PK

Thanks for great work and a nice demo on YouTube.

In the demo, you showed how passing an empty string when expecting one char, resulted in an error that crashed PostgreSQL, albeit with a nice user-friendly error message from Zig, which is of course much better than the segfault C would cause.

However, crashing a production PostgreSQL database just because there is a bug in a Zig extension database function, might not always be desirable.

If possible, it would be nice with a setting that allows logging the error and just returning NULL instead of crashing.

We show how to build the extension using the Postgres from the development environment, but the next step is installing the resulting extension, or building it for the target production DB.

When using zig build it automatically defaults to zig build install. Out of the box one has an install and uninstall target.

When running zig build install our builds do compile the extension and copy all artifacts into the prefix path, which defaults to zig-out. The zig toolchain "jails" the install path so to say.

If you want to install the extension on your host postgres installation you might need to run the command via sudo. Unfortunately if the artifacts do not exist yet sudo would also affect the compilation (and ownership of the build artifacts).
The current workaround is to install the extension twice via:

$ zig build
$ sudo zig build -p $PG_HOME

The first call will install the extension into zig-out and the second call will install the extension on the host.

Internally we use $PG_HOME to determine the location of pg_config. If set correctly in step 1 nothing would be rebuild.

Using $PG_HOME on the command line feels redundant and might be confusing to our users.

As a first step I would like to update our build support to separate compilation from install. We already introduce custom steps in our build scripts like zig build pg_regress and zig build unit for testing. I would like to introduce another build step named compile that will only compile the artifacts, but not install them yet. CLI usage will become:

$ zig build compile
$ sudo zig build [install] -p $PG_HOME

Discussion on Discuss also proposed to introduce a deploy step. That would work similar to zig build install but would 'escape' the jail by copying the artifacts directly to the folders given by pg_config. CLI usage would become:

$ zig build compile
$ sudo zig build deploy

Note: When using zig build install we already used pg_config --<dir name> to determine the target folders. But encourage by how the zig build system installs files we use the configured install-prefix path instead of the absolute paths. In order to implement support for deploy we would either need to implement our own file/directory copy steps to have better control over the placement or take the easy route and have the deploy step recursively call zig build install -p $(dirname $(pg_config --bindir)).

The readme is getting quite big and it is becoming difficult for users to find the right information or we didn't yet document things properly. To improve the DX and especially getting started experience I would like to split the readme out into a proper documentation.

TODO: sections/structure?

For some projects the accompanying SQL file can become quite large. I'd love to have support to split the SQL file for development purposes and combine them at build time.

Due to SQL files being statements being executed one after another users must be able to correctly configure the order of those files.