pg_cron VS pgsql-http

[Postgres Extensions] pg_cron 1.5.2 (new projects only) now supports sub-minute schedules. PR

(Your PostgreSQL installation might already have pg_cron available, but if not, you would need to install it)

I’d set up citusdata/pg_cron in 14, so I’ll need to set that up in 15 as well.

Functions can be executed via a database query or on a regular schedule. Trigger functions are a special type of function that are covered in a previous article. They provide a way to execute an action based on a database event.

* extraction and loading: the psql-http PostgreSQL extension which is available in Supabase (but not all services like AWS RDS). Not sure how it works with OAuth but something to look into. * automation: use pg_cron to automate the ingest. * transformation: leverage Postgresql JSON functions.

A low-level alternative is using a PostgreSQL-side facility like https://github.com/citusdata/pg_cron - this, however, requires installing a PostgreSQL extension.

If you just want scheduling queries, you can use this https://github.com/citusdata/pg_cron

I don’t understand the question https://github.com/pramsey/pgsql-http

I am trying to use the supabase http rest client extension to fetch data from an external API. Following the supabase docs and the GitHub repo readme, I have not been able to successfully make a request that requires auth, specifically an API key in the request header with key x-api-key.

- Hasura Remote Schema (https://hasura.io/blog/tagged/remote-schemas/)

If you want more control over the web API and you were going to fetch the data within your Python back-end and process it there, for some use-cases (not all, but some), there are options:

- pg_http (https://github.com/pramsey/pgsql-http)

Life is about trade-offs. Doing the work in SQL is not without its drawbacks, but it's also not without its benefits, and that's true for doing the work in a general-purpose language as well. Whatever the drawbacks of doing it in SQL, one of the benefits has got to be eliminating the impedance mismatch (for people who regard that mismatch as a problem, and the OP seems to be one such person). What I claim is that doing the work directly in the database shouldn't be ruled out in general (the specifics of a given use-case may rule it out in particular) any more the the other common patterns (API hand-written in Python, for instance) shouldn't be ruled out in general.

You could e.g. use the trigger to call http api using e.g. https://github.com/pramsey/pgsql-http

I do this all the time just with Postgres functions. Just turn on the following extensions: http (https://github.com/pramsey/pgsql-http) pg_cron (https://github.com/citusdata/pg\_cron)