In the last four posts of our series on writing Postgres Extensions, we got the basics covered types and operators, introduced a debugger and completed the test suite.

Now let’s add another type and see how we can organize the code base when it grows.

In Part III about Writing Postgres Extensions we fixed a serious bug using LLDB debugger and completed the base36 type by using type casts. Now it’s time to recover what we’ve actually achieved – and to do some more testing.

In the last post about Writing Postgres Extensions we created a new data type base36 from ground up. However we left with a serious bug causing our server to crash.

Now let’s hunt that bug down with a debugger and complete the testsuite.

In the last post about Writing Postgres Extensions, we covered the basics of extending PostgresSQL with extension. Now it’s time for the fun part – developing our own type.

Postgres has a ton of features and offers a wide range of data types, functions, operators, and aggregates. But sometimes it’s just not enough for your use case. Luckily, it’s easy to extend Postgres’ functionality through extension. So why not write your own?

One of Postgres’ most powerful features is its extensibility. Although Postgres offers a large number of data types, functions, operators, and aggregates, sometimes you may still want more. Postgres itself already comes with a large amount of additional extensions. Even more can be installed through the PostgreSQL Extension Network and if that is not enough for you, you can also write your own.

However, there isn’t a standard tool for managing Postgres dependencies in applications. To avoid falling into the dependency hell and to enable lean extension development, we developed pgbundle - the Postgres extension management tool.

This article will show you how to create a network with 5 virtual machines which have public IP addresses and can be accessed via Internet. Virtual machines will run on Gentoo.

I hate writing tests. There’s only one thing I hate more: not having tests. So I like it when writing and running tests for anything is easy.

In part 1 of Rex in practice series, we got started with describing our infrastructure as code. All of those automation bits are kept in git repositories. They are nothing but code after all. Since they are code, we want them covered by tests.

At adjust we use (R)?ex extensively to automate tasks related to our infrastructure, and we also started to use it for application deployment.

We would like to share our use case with this tool, highlighting some of its features through a series of introductory posts and examples.

Facebook does it, Google does it, Twitter does it. There are many companies that create databases and lists for you to be able to re-engage and re-target your mobile app users. But why not do it yourself and be independent of any 3rd party to tell you who your users are. Today, as a first article of a series, we want to show you the theoretical basics of user databases and why you should run them yourself.