Run setup when creating extension

[v0idpwn]

Closes #32.

[ChuckHend]

This looks good. I'll take a look at the tests. They have had issues ever since we made pg_partman an optional dependency.

[ChuckHend]

Looks like CI is installing pg_partman into the pgrx managed postgres 15.3, but tests are now running on 15.4, which looks like was released today.

[ChuckHend]

Looks like CI is installing pg_partman into the pgrx managed postgres 15.3, but tests are now running on 15.4, which looks like was released today.

hopefully fix that problem over in #39

[v0idpwn]

Rebased into main and tried to add a test. The toolchain is a bit new for me, so maybe I messed up :)

[ChuckHend]

This is going to be trickier than I expected :(

• pgmq_meta its not currently owned by pgmq, but it should be. I'll have to think how we can handle that, it might be combination of a migration and the init?
• there's two Rust client API, pgmq::PGMQueue and PGMQueueExt. PGMQueueExt is has a subset of features of the other, but can be run without the extension. PGMQueue still needs to create pgmq_meta, so some of the tests are probably failing for that reason. That part would go somewhere near here:

  pgmq/core/src/lib.rs

  Line 237 in 326d512

  let setup = query::init_queue(queue_name)?;

• looks like one test is failing due to pg_partman extension not being created, thats a bug not related to this PR that slipped through. CREATE EXTENSION pg_partman just needs to happen somewhere before here

  pgmq/tests/integration_tests.rs

  Line 101 in 326d512

  let test_duration_queue = format!("test_duration_{test_num}");

  I can patch that

[ChuckHend]

I think we won't be able to use the IF NOT EXISTS part since pgmq does not own the existing tables. Might be tricky, I'll have to think how we could handle that.

[v0idpwn]

pgmq_meta its not currently owned by pgmq, but it should be. I'll have to think how we can handle that, it might be combination of a migration and the init?

I don't really follow this. In my manual tests, it seemed to be owned by the extension (the queue tables, though, weren't). The only case I see where this would happen is if the pgmq_meta table was created manually (for example, by a previous version of the extension) and the extension was installed again. I can try to investigate further, though.

[ChuckHend]

I don't really follow this. In my manual tests, it seemed to be owned by the extension (the queue tables, though, weren't). The only case I see where this would happen is if the pgmq_meta table was created manually (for example, by a previous version of the extension) and the extension was installed again. I can try to investigate further, though.

An extension may only use CREATE ... IF NOT EXISTS to skip object creation if the conflicting object is one that it already owns.

I think I ran into this once before and I did not had much luck using IF NOT EXISTS in the extension SQL if its in the schema that is owned by the extension. The desired behavior we want is for folks running create extension pgmq for the first time, pgmq_meta is created automatically. Users who already have pgmq installed, they should run ALTER EXTENSION pgmq UPDATE TO '<new-version>', and that would not break anything for them. So typing this out, maybe this just means the extension_sql! should just remove the if not exists part?

[v0idpwn]

Additionally, I think you probably want to drop all tables related to the extension if the extension is dropped. We'd need all the tables to belong to the extension so this is done automatically. Unless there's other way.

[ChuckHend]

Additionally, I think you probably want to drop all tables related to the extension if the extension is dropped. We'd need all the tables to belong to the extension so this is done automatically. Unless there's other way.

Agreed. It'll be quite a bit more scope if we want to handle all of that right now. Alternatively, we could put a fix into list_queues() directly so it doesn't crash, and handle all of the object ownership in another body of work.

[v0idpwn]

I will give a stab to the "complete solution" in the weekend, maybe I can make it work. If not, I agree on reducing scope.

[ChuckHend]

I will give a stab to the "complete solution" in the weekend, maybe I can make it work. If not, I agree on reducing scope.

Sounds good, and I appreciate the help! You can DM me in Slack if you want, https://join.slack.com/t/tembocommunity/shared_invite/zt-20dtnhcmo-pLNV7_Aobi50TdTLpfQ~EQ

[v0idpwn]

Closing this in favor of other changes by Adam.