Handle user referencing private tables

[soedirgo]

IIRC, this issue happened because a user created a foreign key to our queue pk

pg_net/sql/pg_net.sql

Lines 11 to 12 in 5ff8b6b

	create table net.http_request_queue(
	id bigserial primary key,

Then the TTL would not work because doing DELETEs failed, this would also kill the worker on every restart.

Maybe the correct behavior in this case is to warn instead of crashing - though dying might also be good to avoid having excessive rows in the queue.

Originally posted by @steve-chavez in #43 (comment)

[soedirgo]

One small win: rename http_request_queue to _http_request_queue.

This is a private API, so when a user interacts with it, all bets are off. As far as I'm concerned, this is working as intended.

So the improvement to be gained here is on UX of user errors.

Maybe the correct behavior in this case is to warn instead of crashing

I'm not sure how to go about warning the user that the DELETEs failed. Can you clarify?

[steve-chavez]

Maybe the correct behavior in this case is to warn instead of crashing
I'm not sure how to go about warning the user that the DELETEs failed. Can you clarify?

Ah, my ideas where not clear when I mentioned that(they were not directly related to DELETEs).

But I was thinking that we could have a guc like pg_net.is_worker_on=true and when this is false(worker down) calling all the functions(like net.http_get or net.http_post) would fail. That would prevent having a lot of http requests on the queue.

[steve-chavez]

One small win: rename http_request_queue to _http_request_queue.

I agree. Also, right now the worker crashes/restarts forever when there's a TTL failure - it should only die once and pg_net functions should refuse to work when the worker is down.

[steve-chavez]

Another simple way is to just remove the PKs of the tables. This should also help with stability in the meantime as inserts will be faster.