Last week was a very odd conjunction of coincidence I’m still trying to understand. The aftermath of which left a reverberating melancholy and nostalgia, difficult to dispel, and all too tempting to embrace. It was one of those times where I question the entropy of the universe itself, as pure serendipity would be an impossible convergence. And yet.. An Expert Opinion I drove to Chicago on Tuesday to present a talk on the pg_timeseries extension to the Chicago Postgres User Group.

Though there is unpacking yet to do, we’re settling in rather well. It’s just a matter of time now, as all things usually become. I no longer become hopelessly lost driving around without navigation. Jen is making progress on her office. Fun times all around! What’s important is the core of the house is essentially done, and we can work from there. Nice, eh? The sideboard / TV-stand is now, as is the cabinet bookcase.

Not every database-backed application needs to be locked down like Fort Knox. Sometimes there are even roles that leverage blanket access to large swathes of available data, if not every table, simply for auditing or monitoring purposes. Normally this would require quite a bit of preparation or ongoing privilege management, but Postgres came up with a unique solution starting with version 14: predefined roles. This topic comes up relatively frequently in Postgres chats like Discord, Slack, and IRC.

The dust has mostly settled and we’re finally unpacking in the new house. Since it’s Memorial Day, I’m taking some time to rest and gather my thoughts to chronicle this whole affair. There’s still a lot to do, but hopefully the most grueling elements have passed. In Closing Our closing date for the house was May 17th, meaning we could take possession later that day. It would be a good opportunity to get a second look to refresh our memories and drop some emergency supplies off to make sure there was room for the cat carriers on Monday.

Sometimes when we have an existing database and schema full of tables, there comes a time when we need to perform a migration. Maybe it’s because we want to move to or from a cloud service. Perhaps we have a small database and want to do a quick version upgrade via dump / restore. Whatever the reason, we may decide to clean up some technical debt while we’re making the transition.

Many Postgres experts recommend against creating objects in the public schema. This is the default schema that exists in nearly all Postgres databases, and there are often implicit grants that could make our objects available in unexpected scenarios. It’s also a cluttered namespace if all tables, views, functions, etc., are created there by default. Using it is sloppy and makes future data or operation segregation much more difficult.

So how can we move a bunch of existing stuff out of the public schema safely?