PG Phriday: Stuck in the Middle with Postgres

Earlier this year, I implied Postgres was some kind of [intlink id='pg-phriday-alien-incursion']super middleware[/intlink] for dragging data out of every external resource it could locate. But that example only used the Postgres foreign data wrapper to contact another Postgres server. Why be so unimaginative? The future is as unlimited as it is terrifying.

[caption id="attachment_1401" align="aligncenter" width="600"] Meet the new Postgres mascot[/caption]

PG Phriday: Through the Window

Now that we know how Postgres [intlink id='pg-phriday-in-the-window']window functions work[/intlink], why not play with them a bit to get a better understanding of their capabilities? So long as we understand window functions are applied after data gathering and aggregation steps, much of their mystery and complexity is defanged. Let’s start actually using them for stuff!

[caption id="attachment_1396" align="aligncenter" width="480"] Captain Murphy is tired of your nonsense[/caption]

PG Phriday: In the Window

I’ll be the first to admit that I found Postgres window functions fantastically confusing when I first encountered them. They’re a powerful and versatile tool for building reports and summaries, but that functionality hides behind a fairly steep learning curve. One of the ways to combat their inherent complexity is to fully explore how they work, instead of just trying to wrap our heads around the expected results.

PG Phriday: Down in the Dumps

These days with multiple Postgres database environments a commonality, it’s not unheard of to copy data from one to another. Perhaps a production extract is necessary to properly vet data in a staging environment. Maybe the development environment needs to update its data to reflect an especially pernicious and intractable edge case someone observed. In any of these scenarios, we are likely to extract data from multiple tables to import it elsewhere. The question is: how?