Skip to content

Open Source Involvement¶

The order of entries on this page is an attempt to highlight projects based on recency and impact.

If any of these sound exciting to you and you'd like to support my work, please consider sponsoring my work 1.

Current¶

Omnigres¶

Omnigres makes Postgres a complete application platform. You can deploy a single database instance and it can host your entire application, scaling as needed.

Note

I am most actively involved in this project at the moment.

libfyaml¶

I am actively contributing to this YAML library for C.

pgrx¶

Previously known as pgx

I contribute to pgrx, a library to build Postgres extensions in Rust with, on an ongoing basis, primarily driven by needs of clients and my interests.

pg_graphql¶

I am contributing to pg_graphql as requested. More contributions expected.

wrappers¶

I've helped refactoring Supabase wrappers (a framework and a collection of Foreign Data Wrappers for Postgres)

Postgres¶

So far, I've proposed two small patches:

git-paravendor¶

I am developing a tool to vendorize dependencies alongside in the project repository.

This helps with workflows in absence of a good internet connection, and ensures that dependencies that are gone are not going to have an immediate disrupting impact on your project.

Ideas 💡¶

These are some of the projects I would like to work on, but haven't started yet. If any of these sound exciting to you and you'd like them to be implemented, please consider sponsoring my work 1.

In-memory access method¶

For cases like long-term in-memory caches, it'd be great to not have them stored on disk at all (that rules out unlogged tables) and have them persisted across sessions (that rules out temporary tables).

I am eyeing the idea of implementing a table/index access method that will work in shared memory.

Notes

I think that in order to make it easier to deploy, it should not use Postgres shared memory and instead work with operating system's shared memory directly.

Postgres Patches¶

Object Synomyms¶

Sometimes naming objects the way they were designed (either in Postgres or in an extension) is problematic, especially when you need to qualify name to the schema or import the whole schema by adding it to search path.

Oracle has support for synonyms for this exact reason.

Postgres doesn't, but it'd be great to have it.

Enable overriding hard-coded paths in postgresql.conf¶

The fact that many paths are hard-coded in postgres during compile-time can be frustrating at times. No way to change that without recompiling it. It'd be great if postgres and pg_config were able to do this.

How can this be implemented?

There's src/port/pg_config_paths.h generated when configuring Postgres that hard-codes all these paths.

What I've done so far is augmenting it with something like:

const char * _PGSHAREDIR = PGSHAREDIR;
#undef PGSHAREDIR
#define PGSHAREDIR ((const char *)getenv("PGSHAREDIR") ? : _PGSHAREDIR)

Now, of course, this getenv call would have to be changed to attempt retrieving the string from the configuration setting.

Also, pg_config would need to be able to take an option to point to postgresql.conf.

Shell Scripting Language Compiler¶

A simple imperative language intended to be used for shell scripting. However, it won't have an interpret. Instead, it'll compile code to targets like Bash, Dockerfile, etc. The idea is to have a simple and sane language for shell scripting without requiring users to install an interpreter.

Features may include some basic support for parallelization, JSON 2 and tabular data processing, etc.

Better C as a C superset¶

Codename "Spicy Language"

Some people have tried to solve C's problems by creating new languages (Zig, D), some went even a bit further than just C (Rust, Nim) but I wonder if C itself can be saved using some magic. I really don't fancy the idea of keeping rewriting libraries in the new languages every couple of years.

What I want is Better C that is still 100% C. That is, it compiles existing C code just fine. It doesn't change any of the existing semantics. But it does offer extra features on top of it.

First thing I would like to fix is with regard to the flat namespaces and conflicts. Perhaps something along the lines of namespaces (especially for dependencies), external symbol renaming, etc. These things make our lives just miserable at the worst time.

I'd like it to fix scope exits (without out-of-order statements), and a few other things.

It can also perhaps with minor annoyances of C such as the necessity for forward declarations.

It'd be great to implement Spicy as a set of syntax transformers that can operate both on the source code level but also preserve state across translation units to fix issues that arise outside of the translation unit boundaries. It can be developed as a drop-in replacement for cc, ld and other tools to be aware of some of the user's intent 3.

Virtual Machine Shim for libcrun¶

Using containers on a development machine is fun if it is a Linux machine. Otherwise, one has to resort to virtual machines.

Lately, I've grown to appreciate having less dependencies that require separate installation. For that reason, relying on docker, podman, runc, crun or other tools as binaries doesn't seem attractive anymore. I want to be able to use libcrun on both Linux and macOS alike. With no change in API. Perhaps even use Virtualization Framework on macOS 4.

Application Operating System¶

Codename "ParaOS"

We build software systems on top of many layers (in the name of focus, efficiency and to avoid reinventing the wheel.) Battlefield-tested foundation that addresses common needs is a great time, money and energy saver.

However, many of the layers we use today have been designed for a different environment, needs and deployment size.

We (predominantly) write code in programming languages that were intended to make programs that run on a single computer, put that code into files and deploy instances of operating systems, the foundations of which were designed about 50 years ago, primarily concerning itself with serving the resources (CPU time, memory, persistence, networking and other peripherals) of an underlying computer to multiple users and their programs.

The systems we develop these days span multiple nodes and heavily rely on lage-scale, highly-available persistence capabilities as opposed to dealing with local files, multiuser access, etc.

So, what if built an operating system for these applications?

Unlike traditional operating systems, this system would focus on providing building blocks (operational guarantees, APIs, code mobility, etc.) for building applications that span multiple computers as opposed to focusing on serving the underlying hardware to applications as in programs in user space.

Past¶

Below are the contributions that I am not using or involved in actively anymore (but others could be). Some projects maybe in a derelict shape.

Ruby on Rails¶

A few minor contributions in the past and recently.

Hotwire¶

I've contributed to Turbo Rails a bit when developing my startup HackerIntro.

wasm.rs¶

I've tried to build a few WebAssembly-related libraries and a community. The attempt has fizzled out but I still think there's something to it. At least the domain name is interesting!

graphql-java-annotations¶

I've conceived the project long time ago and it has since been taken over.

Elixir¶

In the early days, I've contributed to Elixir programming language as I was deeply involved in the Erlang community and was looking for ways to improve my code.

erlzmq2¶

I've built this better-performing ZeroMQ wrapper many years ago.

  1. You can create a custom monthly or one-time amount. Send me a message to discuss details. ↩↩

  2. Parsing JSON in pure Bash sounds like fun, right? People have done it, though. Maybe it can be written in the language itself. ↩

  3. There are some fun ideas like delaying compiling object files until they are used for something so that they can be manipulated before the final steps. ↩

  4. I know it doesn't have a great API and it has tons of deficiencies. But I think I may have a workaround or two. ↩