Question: Does this work on hosted providers?

[dwelch2344]

I'm just discovering the awesomeness that is Tembo via this project, so forgive me if this is a stupid question.

Is this something that can run on top of any "standard" PG instance out there? ie AWS RDS, GCP CloudSQL, Heroku, etc.

[ChuckHend]

If the cloud providers add it to their supported extensions, then there is no reason it cannot. I think it requires filing a support ticket to get a new extension added. The work discussed in #199 would make it a bit more portable (re-writing certain parts from Rust into pl/pgsql).

I would say it is generally very difficult to get new extension added to most Postgres providers out there. Its available now on our free/hobby tier at https://cloud.tembo.io/ though. You can install it via UI/API into any Tembo instance, or create the "MessageQueue Stack" and have it pre-installed.

[ConProgramming]

Could this run as Pl/rust for a trusted language extension? https://aws.amazon.com/blogs/database/build-high-performance-functions-in-rust-on-amazon-rds-for-postgresql/

[ChuckHend]

@ConProgramming, I have not built with PL/Rust so I cannot say for sure. Partitioned queue's depend on pg_partman, which I am almost certain will not run as PL/Rust, however most cloud providers already provide that extension.

[dwelch2344]

Oooo ive used a number of other pl/X langs before, but haven't yet dabbled in rust. Happy to take a stab at this. If anyone wants to collaborate, lmk

[ChuckHend]

Oooo ive used a number of other pl/X langs before, but haven't yet dabbled in rust. Happy to take a stab at this. If anyone wants to collaborate, lmk

All the extension functions are now in pl/pgsql . The build/packaging system is still in Rust though. We will most likely be moving that over to pgxs soon.

[ConProgramming]

Oooo ive used a number of other pl/X langs before, but haven't yet dabbled in rust. Happy to take a stab at this. If anyone wants to collaborate, lmk

All the extension functions are now in pl/pgsql . The build/packaging system is still in Rust though. We will most likely be moving that over to pgxs soon.

Ah wasn't aware extensions functions are now in pl/pgsql, that means this should work on hosted providers without a problem yes? Just running the pl/pgsql on a server?

[ChuckHend]

Ah wasn't aware extensions functions are now in pl/pgsql, that means this should work on hosted providers without a problem yes? Just running the pl/pgsql on a server?

I think you might currently be able to copy/paste the functions into any postgres that has pl/pgsql installed, but it will not show up to Postgres as an extension. For example, if you ran cargo pgrx schema today, that will give you all the function and object definitions, but create extension pgmq will not work unless a hosted provided installs the SQL files/control file onto the Postgres server.

[ConProgramming]

Ah wasn't aware extensions functions are now in pl/pgsql, that means this should work on hosted providers without a problem yes? Just running the pl/pgsql on a server?

I think you might currently be able to copy/paste the functions into any postgres that has pl/pgsql installed, but it will not show up to Postgres as an extension. For example, if you ran cargo pgrx schema today, that will give you all the function and object definitions, but create extension pgmq will not work unless a hosted provided installs the SQL files/control file onto the Postgres server.

I'm not well versed in postgres extensions - will it matter if its shows up as an extension? Will any functionality be impacted?

[ChuckHend]

Will any functionality be impacted?

I'm not really sure how the functionality would be impacted since the way they are currently written, its assumed all the objects are members of the pgmq extension (but maybe that doesn't matter). You certainly would not be able to do thing like alter extension pgmq update to upgrade the version, or drop extension pgmq to remove all the objects from the database.

That being said, I would not recommend copy/pasting the code around for production use cases. The idea with packaging pgmq up as a TLE is so it could be installed anywhere that TLE is supported.

[ConProgramming]

Will any functionality be impacted?

I'm not really sure how the functionality would be impacted since the way they are currently written, its assumed all the objects are members of the pgmq extension (but maybe that doesn't matter). You certainly would not be able to do thing like alter extension pgmq update to upgrade the version, or drop extension pgmq to remove all the objects from the database.

That being said, I would not recommend copy/pasting the code around for production use cases. The idea with packaging pgmq up as a TLE is so it could be installed anywhere that TLE is supported.

It would be great to have as a TLE, for Aurora support and Supabase support!

What's the difficulty to implement that / what's blocking that?