Extension upgrades discussion

[gonzalezzfelipe]

Hey there,

We at TxPipe are developing Mumak, an extension to interact with Cardano CBOR data directly.

Upgrades are a pain for us because we have many indexes that depend on the extension. Therefore, when updating the extension (even if the update solely involves adding some functions), we see no option but to drop cascade the extension, loosing all the indexes, and then having to recreate them (~10 hours).

With that in mind I was wondering:

• The first item on the TODO list is Automatic extension schema upgrade scripts, how close to being ready is that feature?
• Is there an alternative that we are not seeing to improve how we do the extension upgrades?

For know, what we were thinking is to generate many subextensions (mumak-blocks, mumak-txs, mumak-utxos, mumak-addresses, mumak-misc) and then handle the updates as we do now, with the benefit of having smaller blast radiuses.

Looking forward to read what you have to say about this, it would be very benefitial for us to improve the upgrade flow.

[workingjubilee]

The first item on the TODO list is Automatic extension schema upgrade scripts, how close to being ready is that feature?

When that TODO list was drafted, it was assumed that pgrx would develop in a different way than it has. It is not actually on the roadmap AFAIK.

[eeeebbbbrrrr]

Is there an alternative that we are not seeing to improve how we do the extension upgrades?

You can make your own extname--oldver--newver.sql upgrade scripts, following the outline provided by the Postgres documentation for extension upgrade scripts. You put them in your crate's sql/ directory, and pgrx will properly manage the files.

You have to write them yourself, but that's at least consistent with how C/PGXS-based extensions work.