Magistrate Postgres Blog by Devin Clark

Gravatars and Postgres 12 using Generated Columns

2020-07-08T00:00:00+00:00

Generated columns are an exciting new feature of Postgres. They allow you to replace some of your existing trigger logic in a faster and easier to read way.

create table users (
  id serial primary key,
  name text not null,
  email text not null,
  avatar_url text generated always as ('http://gravatar.com/avatar/' || md5(email)) stored,
  created_at timestamptz not null default now(),
  updated_at timestamptz not null default now()
);

The interesting part of this block of code is where the avatar_url column is being created. It is creating a new column that is generated and stored on disk using the value of another column (email). That also means if a user's email is updated, the avatar_url will also be updated with the correct Gravatar url. This functionality was added in Postgres 12.

Let's say we decide to show an avatar that is more optimized for our app. Gravatar allows you to pass a size parameter in pixels for the returned image. This can be accomplished with Gravatar by adding s=200 as a query parameter. All this takes is altering the column.

alter table users drop avatar_url;
alter table users add column avatar_url text generated always as ('http://gravatar.com/avatar/' || md5(email) || '?s=200') stored;

You might be wondering why you would store this value in the database instead of generating it in your app. Computing MD5 hashes isn't a very fast process (by design), especially when it needs to be done anytime an avatar needs to be displayed. Storing the calculated value will certainly speed things up.

For more information about the possible configuration of Gravatar URLs, see this article from the Gravatar documentation.

Rob Conery shared another use of generated columns using json columns that is worth checking out.

This is just one reason we love Postgres, but there are so many other things to love about it! If you liked this blog post, and want to learn more about what Postgres has to offer, sign up for our mailing list!

Case-Insensitive Text Columns in Postgres with citext

2020-08-15T00:00:00+00:00

Recently we heard from a friend that they were curious if there was a better way to work with case-insensitive text columns in their Postgres database. They were frustrated because they found a bug where part of their application considered the column to be case insensitive and another part did not.

The column we were asked about was an email column that would be used lookup users and would certainly benefit from an index. This got us thinking about indexing case-insensitive text. Typically, the column would be defined as a text type, and everywhere it is referenced you would call lower() on the value.

That has a few drawbacks though. You have to remember to call lower() on the value, a unique constraint on the column will be case-sensitive, and it will not use an index (unless it is an index on lower(email)).

So, let's start with a typical user lookup query.

select * from user where lower(email) = lower(?);

We can improve this by changing up our table schema a bit. We are going to leverage a Postgres extension to get access to a new column type, citext (case insensitive text).

But first, we need to check to see if the extension is available on our database. This can be done by running the following query on our database or by looking at the extensions tab of our magistrate dashboard.

select * from pg_available_extensions where name = 'citext';

We got a result from running that query so we know it is available on our database. Now we can install the extension to our database with this query.

create extension if not exists citext;

Now that we have all of that set up we can change email to use the citext type we just added.

alter table users
  alter column email type citext;

Now our user lookup can be simplified to this query because the citext type is handling the lower() calls.

select * from user where email = ?;

This change squashed our friend's bug, and now our friend knows about citext for future case-insensitive text needs!

citext is just one of the many Postgres extensions we love. If you liked this blog post, and want to learn more about what Magistrate has to offer, sign up for our mailing list below!

Storing Timezones in Postgres

2020-10-01T00:00:00+00:00

Storing a user’s timezone in Postgres can be an interesting task in apps. Often, this is accomplished by generating a hardcoded list of every timezone in the backend (or worse the frontend JavaScript) and storing an item from that list in the database for each user. This hardcoded magic list is both difficult to build accurately and hard to maintain. Timezones change more frequently than you would imagine ...but less frequently than time itself.

Postgres has a system view called pg_timezone_names that has the list of timezones used by Postgres internally. We can use this view to generate a dropdown or other input type for the user to select their timezone. We can filter out some of the timezones in your query (like all the ones that start with “posix/“) because this list is quite large by default.

select name from pg_timezone_names where name not like 'posix%' and name not ilike 'system%' order by name;

Now, we need to figure out the best way to store the selection from our user. We can do this by adding a column to our users table to hold the timezone. The column is a text type because we are only storing the name value from pg_timezone_names.

alter table users add column timezone text;

Next, we want to query the user’s events in the timezone we have for the user. We store the start_time for the events as UTC timestamptz columns. This solution leverages the timezone function in Postgres. AT TIME ZONE zone also works. The last join in this query is optional but it is there in case you need to know the UTC offset or if the timezone is in DST.

SELECT events.name, timezone(users.timezone, start_time)
FROM events
JOIN users ON events.user_id = users.id
JOIN pg_timezone_names ON users.timezone = pg_timezone_names.name;

This could be taken a step further by using the to_timestamp function in Postgres to format the dates, and keep the application from formatting dates at all.