3 ms·
1) “NOTIFY” should be eligible for prepared statements to assist in the case where untrusted values is part of the “channel” or “payload”. I had to write some
by tezza 4y ago
1) “NOTIFY” should be eligible for prepared statements to assist in the case where untrusted values is part of the “channel” or “payload”.
I had to write some ugly stored procedures to attempt sanitising myself
2) Query batching where queries are submitted to a database together and then results are returned. If this could be done without a connection per query that would be awesome. The use case is a global truth database needing 1 write to 20 reads… If the server is in the UK and the client is in Fiji then batching the 20 reads together is a massive latency win.
- ntarora 4y agoCan’t you do number 2 with Postgres pipelining? Here’s an article from bit.io (serverless Postgres w/ data repos) their example is inserts but also works for read ops. https://innerjoin.bit.io/the-distance-dilemma-measuring-and-mitigating-postgres-network-latency-76f6cd1a6c57 https://innerjoin.bit.io/the-distance-dilemma-measuring-and-... https://www.postgresql.org/docs/current/libpq-pipeline-mode.html https://www.postgresql.org/docs/current/libpq-pipeline-mode....
- jeltz 4y agoYou can do (1) using "PREPARE s AS SELECT pg_notify('foo', $1);". PostgreSQL also supports query batching via pipelining.