Personally I think there was nothing wrong with returning NULL. "But if people don't check for it it crashes their programs!" Good! Let it crash loudly! Then they notice and fix the issue.
Also I think it could have returned ":". Given the file format of /etc/shadow and /etc/passwd I don't think it's possible to have a : as a value for anything.
> Also I think it could have returned ":". Given the file format of /etc/shadow and /etc/passwd I don't think it's possible to have a : as a value for anything.
I wonder if somebody else would have thought the exact same thing in a different (non-/etc/*) context, and then you get the same effect in a more obscure manner.
What I think would make sense is a change to the C API where the error code is an out parameter and not that ugly thread local errno. But I guess that's not big enough of an issue for people/languages that use libc as system call interface.
You’re right; technically read–only access to a string only needs to know the pointer and length. I didn’t take the time to polish my message very much.
Errorno is stupid and annoying too, but I think that’s mostly a libc thing rather than a kernel thing. The syscalls themselves simply return error codes in a register as a return value. Worth fixing though.
Compilers often just build up more and more data structures in memory until the end when they then release everything more or less at once. With an arena you can then just throw away the whole arena at the end, assuming there are no resource handles that need to be closed in drop().
A long time ago I read an article about someone speeding up a C++ compiler that is itself written in C++ (was it g++? maybe clang?). They simply patched out delete so it did nothing. The compiler used marginally more memory but ran much faster, since releasing all the small objects one by one is just useless work at the end of the compilation.
A GCed language has a similar behavior and could therefore be fast in that case. It just builds up all the objects and then when the program exists it doesn't have to GC them all, it just throws away the whole process memory. So I can imagine one could "optimize" a compiler written in a GCed language by deactivating the GC.
I read on here a few months ago about some high-frequency trading system being written in Java and running with no garbage collector enabled, because the application is closed at the end of trading each day and it's extremely fast without garbage collection.
We're currently use pgvectorscale. Some questions:
- Will pg_vectorsearch eventually also support vectors bigger than 1968 dimensions? E.g. VoyageAI can create embeddings with 2048 dimensions (but we don't actually need that at the moment, only 1024).
- Why did you choose C this time and not Rust, as you did with pgvectorscale?
- Why did you not just extend pgvectorscale with another index type instead of creating a whole new extensions?
- Almost certainly. In fact, there is already a submitted PR contribution for larger dimensions.
- C is much better integrated into Postgres, doesn't require pgrx. Given also experience developing pg_textsearch, and the acceleration from AI-assisted development and testing, have moved back to more C with extensions.
- Two reasons. First, decision to move back to C. Second, if there ultimately isn't much code overlap, better to keep them separate for easier adoption (smaller footprint and security/correctness envelop)
reply