Open CGenie opened 4 months ago
Hi @CGenie, thanks for raising the issue. The API around pgmq.detach_archive()
is pretty rough at the moment. The reason it exists is to make it slightly more convenient to implement partitioning on an existing queue archive (creating new partitioned table, renaming old, etc.). The issue you showed above feels like a bug and I will need to think through how we can handle this more gracefully.
There is some ongoing work related to partitioning the archive tables that @shhnwz is handling. I think we can address this during that work.
Well, my overall idea was to get rid of critical errors. I don't use detach_archive
, just gave it as an example.
But I think one shouldn't throw errors in drop_queue
, at least the IF EXISTS
statements give me the clue that this was the initial intention.
I agree. I think the same problem exists on pgmq.create() right now too.
Hello,
We have this code (https://github.com/tembo-io/pgmq/blob/main/pgmq-extension/sql/pgmq.sql#L429) for dropping a queue:
Currently, when I drop a non-existing queue, the first statement fails with an error:
From PostgreSQL docs on
DROP member_object
:We're in a user-called function here, not in an update script. Is there a point of altering the extension itself with queue/archive tables? Please look at 2 other SQL statements: we are careful here not to throw an error using the
IF EXISTS
. There is noIF EXISTS
counterpart forALTER EXTENSION ... DROP TABLE
so maybe we just get rid of thatALTER EXTENSION
altogether?In fact, this causes even more problems. For example:
pgmq
is supposed to be used in highly concurrent environments - I think the less exceptions like that are thrown, the easier it is to maintain the software that uses it.