Comments URL: https://news.ycombinator.com/item?id=49002909

Points: 1

# Comments: 0

A week or two ago I asked Claude Code to write a comprehensive testing plan for a new Postgres feature I wrote, UPDATE/DELETE FOR PORTION OF. I was a bit anxious about how many bugs were discovered as soon as it was merged this spring. Claude found some untested areas, then it wrote more tests for them. I'm not talking about LOC covered, but feature combinations. (I've been meaning to submit this as a followup patch. . . .) Fortunately it didn't find any more bugs.

I sense that testing plan has affinity with the findings in the OP, even though it is far more humble than research mathematics. Even better would be if we knew good ways to express invariants about Postgres's behavior, and then we could ask LLMs to violate them. I'm sure there are good ways already, and the "we" who is not knowing is not "all humans" but "the Postgres team" or just "me".

As a counterexample to the article (heh): even though Claude didn't uncover any new bugs, a human did, just a few days ago. Alas!

That's exactly why I started learning about temporal tables. I had a customer whose app used questionnaires to measure the effectiveness of government social services, and they let people change the questions (and multiple choice options) even after there were answers! Obviously the data was trashed.

I've seen this bug over & over again, where you have a foreign key relationship, and the referenced table changes, but the referencing table needs the old data. Another example is a sale that doesn't capture the product's current price.

Temporal tables mean that you can run your 2022 financial reports and get the same answer you got before.

My own time-tracking and invoicing app has to solve this problem. I also "copy everything" when something changes. I just gave a talk about migrating it to temporal tables: https://illuminatedcomputing.com/pages/pgdata2026-migrating-...

You'll have to decide if your use-case is more "system time" (history of the database) or "application time" (history of the entities). The features here are for application time. I want to make sure Postgres gets system time too, but it's not in v19.

If you want system time today, there are several widely-adopted Postgres extensions that can do that already. I cover them here: https://illuminatedcomputing.com/posts/2017/12/temporal-data...

And actually, application time is managed by you (while system time is managed automatically by the database), so really you can use it for whatever you want.

For system time, a separate history table is a common implementation, sometimes also with partitioning. Here is what other vendors are doing: https://illuminatedcomputing.com/posts/2019/08/sql2011-surve...

Thank you to everyone here saying they are excited about it. I often hear doubts that anyone wants this. Perhaps that's why vendors have been so slow to add it. And thank you 'bonesmoses for writing about it!

We are still missing system time, but if no one else wants to work on it, I hope to tackle that soon.

I have a lot of other ideas for improvement beyond SQL:2011, too. Here is a talk I gave last month about my personal roadmap:

https://illuminatedcomputing.com/pages/pgconf2026-temporal-r...

I've also been vibecoding a lisp REPL to play with the algebra of temporal relational operators (important for the planner): https://github.com/pjungwir/relsim

That overlaps with my attempt to write implementations for temporal semi/anti/outer-join and other relops: https://github.com/pjungwir/temporal_ops

If anyone has comments about what you'd like to see, I'm happy for feedback!

Comments URL: https://news.ycombinator.com/item?id=48505773

Points: 11

# Comments: 1

To me it is more convenient than a VM, since everything is on the host. And it can launch its own VMs without an extra layer.

I don't really know which is more secure. There are hypervisor escape vulns too. And shared folders seem like footguns. For instance in vagrant, guests get `/vagrant` to read/write the host's folder, so you have to be careful what you put where.

The biggest annoyance with an OS user so far is running docker containers. I don't want to add claude to the docker group or give it sudo privileges. I've read that you can set up rootless docker for a user, and even that you can run it side-by-side with a normal system-wide docker, but I haven't tried doing that yet.

He has similar dotfiles to mine, but no secrets. My own home directory is 0700. He has his own ssh key that I added to my github profile, but it's password-protected, and I push/pull for him. He has his own Postgres (non-superuser!) {development,test} {users,databases}.

It's as if he were another developer on the project. If he needs something run with sudo, he asks me. Often we can both work on something in parallel. Unix was supposed to be a multi-user system after all.

A trick I use a lot is that many of his git repos have an extra remote, like this:

    paul  ssh://paul@localhost/~/src/example (fetch)
    paul  ssh://paul@localhost/~/src/example (push)

I'm pretty comfortable with this setup.

I do worry about Linux privilege escalation bugs. I don't trust an AI to understand that exploiting vulns is not acceptable. (I can't help but recall that at my first job I may have misused vim's :! feature to broaden my sudo powers, which were officially limited to editing httpd.conf, when I needed something in a hurry. . . .) I find myself manually upgrading packages more often these days, despite automatic security updates. I don't think Opus would go to the trouble of looking up security vulns, but maybe Fable would, and there have been a lot lately. Maybe some future model will just take it upon itself to find new ones. Or install a keylogger to learn the ssh key password.

But a separate user is nearly the most paranoid setup I've heard of, excepting only a separate machine. So I also question whether I'm sacrificing too much speed/convenience. But really it's still very convenient. I think it's a good way of being efficient but responsible.

If other people see holes, I'd be happy to hear about them.

Comments URL: https://news.ycombinator.com/item?id=44155600

Points: 2

# Comments: 0

    ["foo", "bar", "$1"]

    ["baz", "gar", "$2"]

And then a higher level is just iterating the array, and doesn't have to think about the promise. Like a Python generator or Ruby enumerator. I see that Javascript does have async generators, so I guess you'd be using that.

The "sort of" is that you can stream the array contents without literally splatting. The caller doesn't have to reify the whole array, but they could.

EDIT: To this not-really-a-proposal I propose adding a new spread syntax, ["foo", "bar", "...$1"]. Then your progressive JSON layer can just deal with it. That would be awesome.

Comments URL: https://news.ycombinator.com/item?id=41932536

Points: 1

# Comments: 0

I'm a full-stack developer with 20+ years experience. My specialties are deep Postgres consulting, web development in Rails/Django, and devops with Kubernetes, AWS, Azure, Terraform, Ansible, etc. From time to time I've done projects in Javascript/Typescript (React, Vue, Angular, Node), Java, C#, C, Go, Rust, Elixir, Perl, etc.

I am reliable, easy to work with, quick to turn things around, and a good communicator. I can work solo or on a team, either as lead or a team member. I value client satisfaction as highly as technical excellence.

You can see some of my recent work here:

https://illuminatedcomputing.com/portfolio

https://commitfest.postgresql.org/49/4308/ (Adding SQL:2011 application-time to Postgres)

https://commitfest.postgresql.org/31/2112/ (Adding multiranges to Postgres)

https://github.com/pjungwir/aggs_for_arrays

https://github.com/pjungwir/aggs_for_vecs

https://github.com/pjungwir/active_model_serializers_pg

If you'd like to work together, I'd be happy to discuss your project!: pj@illuminatedcomputing.com

I noticed a couple details that seem wrong:

- You are passing `context` to `log_then_get` and `get`, but you never use it. Perhaps that is left over from a previous version of the post?

- In the fiber example you do this inside each fiber:

    responses << log_then_get(URI(url), Fiber.current)

    responses << get_http_fiber(...)

- Doesn't this leave `responses` with 8 elements instead of 4?

- What does `Fiber.schedule` return anyway? At best it can only be something like a promise, right? It can't be the result of the block. I don't see the answer in the docs: https://ruby-doc.org/3.3.4/Fiber.html#method-c-schedule

- When each fiber internally appends to `responses`, it is asynchronous, so are there concurrency problems? Array is not thread-safe I believe. So with fibers is this safe? If so, how/why? (I assume the answer is "because we are using a single-threaded scheduler", but that would be interesting to put in the post.)

Comments URL: https://news.ycombinator.com/item?id=40963905

Points: 3

# Comments: 0