70 karma · joined March 23, 2012
We'll be continuing to improve and work on the developer experience for postgres and building applications, thanks again!
Always want to make the glide path and ensure folks can run the software replicably on their machines!
happy to help if you run into any issues :)
this is also similar to the non-incremental way TS rolled out in the early days, also causing knee-jerk reactions to TypeScript. However over time, devs found ways to incrementally type JS to TS, and so we've all mostly evolved by now.
If ESM could do similar, allowing for incremental evolution, then it would solve all of the problems. I don't see why cjs and esm cannot co-exist
But if you use "module: true" in your package.json, you are splitting the npm ecosystem into two groups, and it's not moving us forward.
The transpiler not only allowed me to add typing for pgsql-parser but also spawned a suite of TypeScript utilities that are invaluable for PostgreSQL development.
Explore the tools:
pg-proto-parser: https://github.com/launchql/pg-proto-parser pgsql-parser: https://github.com/launchql/pgsql-parser
Additionally, we now have new utilities generated by the proto parser, make sure to checkout the @pgsql/utils! That has some cool features in it:
@pgsql/enums: https://github.com/launchql/pgsql-parser/tree/main/packages/... @pgsql/types: https://github.com/launchql/pgsql-parser/tree/main/packages/... @pgsql/utils: https://github.com/launchql/pgsql-parser/tree/main/packages/...
Hope you enjoy! Please let me know anything you'd like to see!
I do a lot of functional programming and needed dynamic SQL. My personal belief is that ORMs are the wrong interface to creating migrations, and I prefer a pg native, functional approach. This library was actually one of the base extensions of a larger set, that I used this to create higher level structures for creating migrations. So while this is “low-level” you can definitely create stored procedures that do make higher-level if you wish.
I hope some of you find this useful with your projects!
postgres-ast-deparser A pure plpgsql AST toolkit and deparser for PostgreSQL, which can be used to create ASTs and deparse them back into strings in native Postgres. https://github.com/pyramation/postgres-ast-deparser
I ultimately switched to native PG. There were known memory leaks in plv8 and eventually after learning pl/pgsql it became more natural and clean, plus AWS at the time didn't support plv8 which was another incentive not to use language extensions
It seems possible to brute force, however as soon as the interval changes, by default every 30 seconds, the TOTP is now new because time has passed.
But assuming they could do some crazy thing like attempt 10,000 times within that interval, I suppose it's arguable that it should still be secure...
So upon research looks like it's quite easily fixed by comparing all digits individually, and then aggregating if all all true, but continuing the iteration and checks even if a false value has been found. I suppose that would cover this case.
Thanks for pointing this out! Will be adding an issue ;)
The first TOTP implementation I wrote was here was much less efficient, literally the algorithm in steps: https://github.com/pyramation/learn-totp/blob/master/package...
That gist is essentially the pure TOTP algo, but it was missing what we use in industry practice that the RFC was missing... base32 encode/decode.
So I implemented a base32 encode/decode so that the TOTP algo actually works with google authenticator and authy https://github.com/pyramation/totp/blob/master/extensions/%4...
When I found the gist, while the original code worked, the gist was much smaller (used more efficient bitwise operations) and the gist author I collaborated briefly and decided to combine the gist and the code for OSS
I think often times folks who come to postgres often don't know PL/pgsql (as I also didn't) and prefer to user their language of choice. I truly think if our postgres dev environments were better, we'd find more people writing code this way, so I can empathize with why people would prefer python or JS in the db, but at this stage I can't get myself to use those extensions.
FWIW, at one point, AWS didn't support a lot of these (sometimes unsafe) language extensions. So going pure PL/pgsql was the only true path forward. I think now for AWS users, they do support plv8 now, but as you pointed out somewhere in this thread, they are much slower... also I remember plv8 specifically had memory leaks.
the random() seems easily addressable with pgcrypto, but do you have any information or practical examples of how a timing attack would be mitigated here? It seems that speakeasy (a JS lib) or any TOTP that uses '=' to compare would have this issue... what else are you supposed to do?
https://github.com/pyramation/totp/blob/master/packages/totp...
I do agree about making sure you have experience writing PL/pgSQL and would also add that you should make sure you have a good test-driven environment when writing code in the db.
I use graphile and didn't want to have to implement a resolver in JavaScript, keeping logic and integrity of auth systems in the database.