3 ms·
> Like, if you decide to do auth and TOTP in the DB, you'll end up implementing it in PL/pgSQL. Not really? Postgres (as well as other rdbms) support many othe
by e12e 6y ago
> Like, if you decide to do auth and TOTP in the DB, you'll end up implementing it in PL/pgSQL.
Not really? Postgres (as well as other rdbms) support many other languages - I don't see many good reasons to insist on pl/pgSQL for uses like these?
Both python, perl and TCL are part of the standard distribution in addition to pl/pgSQL.
https://www.postgresql.org/docs/13/xplang.html https://www.postgresql.org/docs/13/xplang.html
https://www.postgresql.org/docs/13/external-pl.html https://www.postgresql.org/docs/13/external-pl.html
- smallnamespace 6y agoRight, except if my backend is in JS, there's a cognitive cost to adding another language to the stack. I could use plv8, but there's a more subtle preference here for JS to wrap SQL, rather than the reverse (plus tooling is less convenient, e.g. if you're writing Typescript). My rule of thumb is: SQL great, PL not so much.
- e12e 6y ago> except if my backend is in JS, there's a cognitive cost to adding another language to the stack. Agreed. However, I don't see why not use one of the other mature "real" extension languages other than pl/pgSQL. As for typescript, maybe there's (distant) hope: https://github.com/supabase/postgres-deno https://github.com/supabase/postgres-deno