Add pgmq_read_with_poll

[v0idpwn]

For feature parity with SQS. The implementation is a bit naive: it simply will retry querying for messages on a small interval until the timeout is reached.

To be discussed:

• should we make the interval configurable? maybe it should be a parameter to the function?
• should we receive the timeout in seconds instead of ms, for consistency, considering vt is defined in seconds?

To be done:

• add tests, i only tested manually
• add in rust client without the extension (there we could use async instead of thread::sleep)
• document

[ChuckHend]

• should we make the interval configurable? maybe it should be a parameter to the function?

I think we should make it configurable with a default. Postgres does let us have optional parameters in functions:

pgmq/src/api.rs

Line 12 in df7b396

partitioned: default!(bool, false),

• should we receive the timeout in seconds instead of ms, for consistency, considering vt is defined in seconds?

Seconds seems good to me, to be consistent with rest of pgmq. SQS is seconds too, right?

[v0idpwn]

now() uses transaction start time. This can be pretty useful, but in this case, if we repeatedly query it will always use the same timestamp. I also tried statement_timestamp(), but for some reason while using the SPI I got the same timestamp for different runs 🤔, so I resorted to clock_timestamp()

[ChuckHend]

@v0idpwn , the Rust client library tests are run against the container image with pgmq installed in it - and the image is currently only built when the extension is released. So the Rust client library tests will fail since they are looking for the new long poll function, which wont be released yet.