Adds a basic POC to see whether Deno can be using inside Postgres.
Why:
If we can get this running, then supabase devs get an isomorphic development language - running both on the edge and in the database. This is particularly useful for some of the ABAC ideas, which currently use plv8. This would be a replacement for plv8 and would give developers the benefit of a "write once, run anywhere" environment
POC:
We use pgx to scaffold an extension ✅
initialise the Deno runtime inside the extension ✅
execute a typescript statement within the Deno runtime ✅
Next steps:
Currently this runs as an extension. We need to convert this over to a language extension. There is some prior art here, where plrust is implemented using pgx.
Usage:
cargo build
cargo pgx init # one time
cargo pgx run pg13
Don't use Deno. We could still use plv8, but we might want to add a build pipeline to transpile code into plv8 native code. Here is a discussion with one of our customers on supporting different langauges: https://supabase.slack.com/archives/C02A1CHMWGZ/p1650482428265519
Adds a basic POC to see whether Deno can be using inside Postgres.
Why:
If we can get this running, then supabase devs get an isomorphic development language - running both on the edge and in the database. This is particularly useful for some of the ABAC ideas, which currently use plv8. This would be a replacement for plv8 and would give developers the benefit of a "write once, run anywhere" environment
POC:
Next steps:
Currently this runs as an extension. We need to convert this over to a language extension. There is some prior art here, where plrust is implemented using pgx.
Usage:
see full history here: https://github.com/supabase/pldeno-test
alternative approaches: