The previous article FOSDEM 2013 said to be careful with the PostgreSQL devroom schedule because one of my talks there might get swapped with a slot on the FOSDEM PGDay 2013 which happens this Friday and has been sold out anyway.
Turns out it’s not true, because we still depend on past century technologies somehow. Not everybody will be looking at the schedule on the web using a connected mobile device (you know, you’ve heard of them, those tracking and surveillance devices, if you want to believe Stallman), and as the schedule gets printed on little paper sheets, it’s unfortunately too late to change it now.
This year again I’m going to FOSDEM, and to the extra special PostgreSQL FOSDEM day. It will be the first time that I’m going to be at the event for the full week-end rather than just commuting in for the day.
*I'm Going to the FOSDEM, hope to see you there!* And I’m presenting two talks over there that are both currently scheduled on the Sunday in the PostgreSQL devroom. We’re talking about changing that though, so that one of those will in fact happen this Friday at the FOSDEM PGDay 2013, which has a different schedule, so consider watching for that.
pgloader is a tool to help loading data into PostgreSQL, adding some error management to the COPY command. COPY is the fast way of loading data into PostgreSQL and is transaction safe. That means that if a single error appears within your bulk of data, you will have loaded none of it. pgloader will submit the data again in smaller chunks until it’s able to isolate the bad from the good, and then the good is loaded in.
Another day, another migration from MySQL to PostgreSQL… or at least that’s how it feels sometimes. This time again I’ve been using some quite old scripts to help me do the migration.
This article is about versions 2.x of pgloader, which are not supported anymore. Consider using pgloader version 3.x instead. You won’t need to generate the configuration anymore as pgloader now connects to a live instance of the source database and query its system catalogs for you.
In a recent article titled Inline Extensions we detailed the problem of how to distribute an extension’s package to a remote server without having access to its file system at all. The solution to that problem is non trivial, let’s say. But thanks to the awesome PostgreSQL Community we finaly have some practical ideas on how to address the problem as discussed on pgsql-hackers, our development mailing list.
*PostgreSQL is first an Awesome Community* The solution we talked about is to use templates, and so I’ve been working on a patch to bring templates for extensions to PostgreSQL.