PostgreSQL is an amazing and extensible database, providing a ton of functionality. One of the best parts, in my opinion, is the ability to add additional programming languages to create stored procedures. This allows developers to move business logic deeper into the database itself. Unfortunately, this is often very hard to test in isolation.
The current state of testing in PostgreSQL is to run
which runs a myriad of SQL commands living in files in the
with the results checked against a bunch more files living in the
directory. This works, but is often-times difficult to add into existing
test suites, which ultimately leaves holes in testing.
All databases consist of a handful of operations: Create, Read, Update, Delete, and sometimes Scan. If this sounds a lot like reading and writing files on a disk, it is. At their core, databases need access to both data and metadata. An operating system provides this in a very basic form of a filesystem. As a simple approach to building a database, the reliance on a filesystem is key, as it provides a lot of metadata, and allows us to move forward with one less layer to deal with.
It's silly, really: rebuilding one of the things that has been considered a "solved problem" for a number of years. But, I've always felt that in order to understand a problem fully, one must understand the problems that those who came before us were trying to solve; to take a trip through their design decisions, and to understand why they chose the solutions that they did.