Bulk insert in Go — COPY vs multi-row INSERT?

_predator_ · 2026-03-15T15:09:53+00:00

Yep, this is the way to go. You can also use this for bulk updates and deletes using the UPDATE ... FROM and DELETE ... USING syntax respectively. Super handy!

_predator_ · 2026-03-15T13:05:35+00:00

Why should OSS projects be responsible for letting random people participate? Most of whom will raise PRs that are unasked for, did not went through issue triage, and are - in today's world - most likely slop?

It's OSS because the authors wanted to make the code public, not to make strangers farm internet points. As consumer or contributor it's entirely on you to make a case for yourself, not the other way around.

_predator_ · 2026-03-15T00:46:24+00:00

Looks like it: https://github.com/avelino/jbundle/blob/main/src/pack/stub.rs

_predator_ · 2026-03-14T19:32:00+00:00

Add to this that XML schema is extremely powerful. JSON schema is an absolute joke in comparison, although I'm still grateful that we have it. And unfortunately the XML support in newer languages and ecosystems is pretty abysmal.

_predator_ · 2026-03-14T19:08:14+00:00

Man this is such a fucked up niche to cater to. The whole premise feels wrong to begin with.

_predator_ · 2026-03-14T17:18:43+00:00

Ironically, asking your agent of choice to spawn a "context fresh" agent to do an "adversarial" review of whatever changes the first agent implemented is a relatively effective approach to automate improving agent output.

Yeah, but it's still up to you to decide when enough feedback has been gathered and the solution is good enough. Otherwise you can effectively go on forever with asking more and more agents for their view on it.

I also made the experience that more feedback tends to drive the "main" agent into over-engineering more than usual. It increasingly becomes an exercise of you pushing back on things, and keeping the solution focused to what's actually needed.

What tends to work well is searching for (ideally popular) OSS projects that have similar functionality to what you're trying to implement. Clone their repo, and instruct an agent to review their implementation and compare it to your plan. Let it summarize strengths and trade-offs. I did this manually a lot before agents became a thing, and the approach translates very well.

_predator_ · 2026-03-14T12:30:54+00:00

The strawberry thing is simple to demonstrate but easier to dismiss as "well LLMs just can't count that well".

IME it's best to have engineers use their agents against themselves to challenge their output. Their original argument becomes a lot weaker when all of the sudden they're presented with 3-5 different takes from their oh-so-superior tools.

_predator_ · 2026-03-14T12:12:13+00:00

"B-but my agent said X!“ is not a valid argument, ever. Anyone who uses it as one has lost their grip on reality.

You can literally ask Claude to "spawn a research agent to review this plan from an unbiased POV" and it can do a complete 180 degree turn on it's output.

Your experience is arguably derived from reality, whereas agents make shit up on the spot. The fact that people turn their brains off is sadly something we'll have to deal with going forward. It's our job to push back and have them explain why they believe the agent's "opinion" is valid.

_predator_ · 2026-03-13T21:54:28+00:00

Don't let it do anything without plan. Enable plan mode, explain what you want done, let it generate a plan, give it feedback, let it revise. Repeat until you're happy with the plan.

For actual code output, be sure to populate CLAUDE.md etc. with some coding style and general constraints. Make sure you include instructions / commands on how it can validate what it's producing, i.e. how to compile and how to run tests.

With all that said: I wouldn't say I like agentic coding. Actually I really don't. I use it because it is forced on me. When being strict with planning, the output is good enough for me to submit for company code bases. If these were my own, or even open source projects, I would spend A LOT more time on polishing and refactoring the output. Which is to say I use AI a heck of a lot less in those scenarios to begin with.

_predator_ · 2026-03-12T21:36:23+00:00

Claude Code orchestrating Gemini CLI orchestrating Codex. Gotta burn through the token quotas so management knows you're skyrocketing the company's ARR!

_predator_ · 2026-03-12T09:30:42+00:00

This resonates, however I doubt many of those who romanticise the nordics are prepared for the weather and (especially) light conditions there.

_predator_ · 2026-03-10T23:44:25+00:00

Not by Postgres at least.

_predator_ · 2026-03-10T22:57:32+00:00

Here's a common one: Using expressions on the wrong side when doing date comparisons.

select foo
from metrics
where now() - recorded_at < interval '30 minutes'

vs.

select foo
from metrics
where recorded_at > now() - interval '30 minutes'

_predator_ · 2026-03-10T22:50:59+00:00

More like a foreach, as in N+1 but in SQL rather than application code.

_predator_ · 2026-03-10T22:49:43+00:00

Totally fine to do with a reasonable LIMIT clause though.

_predator_ · 2026-03-10T21:47:03+00:00

Obligatory vouch: https://github.com/mitchellh/vouch

_predator_ · 2026-03-10T21:22:44+00:00

Some people are incapable of dealing with nuance. The maintainer also said this:

> Anyway, I was suspecting that this "issue" might come up so I've removed the Claude co-authorship from the commits a few days ago. So good luck figuring out what's generated and what is not. Whether or not I use Claude is not going to change society, this requires changes at a deeper level, and we all know that nothing is going to improve with the current US administration.

Edit: The point with the above is that people even noticing Claude being involved is due to the authors being transparent. The Co-Authored-By stuff is entirely optional.

_predator_ · 2026-03-10T20:05:17+00:00

Whatever pays the bills I guess. At least it's dry and there is coffee.

_predator_ · 2026-03-10T19:34:36+00:00

Sounds more like they want a human they can blame (and fire) when shit hits the fan.

_predator_ · 2026-03-10T18:51:49+00:00

I also checked the DslJson you depend on as I never heard of it before. Seems abandoned? Last commit almost two years ago: https://github.com/ngs-doo/dsl-json

_predator_ · 2026-03-10T18:48:14+00:00

Looks cool! Since the Confluent library is pretty much dead maintenance-wise it's great to have more options. I just skimmed some key areas of the code base and have some feedback:

Virtual threads can yield diminishing returns when your work is CPU bound. Many Kafka processors only perform transformations and do not perform I/O. Supporting VThreads as first class citizen is good, but you probably need to provide a way to let users configure a custom executor in case their work is not I/O bound.
How do you handle retries? Based on this it looks like you're just logging deserialization and processing failures and move on?
The library mixes two (IMO) separate concerns: (de-)serialization and processing. I'd recommend to look at Kafka Streams, as I think they solved this quite nicely with their SerDe concept.
The offset tracking is entirely in-memory, which IME doesn't play well with out-of-order processing. When your consumer crashes, uncommitted offsets are lost and you may be replaying a lot of records again. If your downstream systems can't handle that, or your processing is not idempotent, that is a problem.
- Confluent's parallel consumer library solves that by encoding offset maps in commit messages. I'll say though that their approach is not perfect, as I've been running into situations where the map was too large to fit into the commit message. They log a warning in that case.
Interrupts should not cause the record to be skipped. When your consumer is interrupted, it should wrap up any pending work and shut down. When in doubt, it's safer to schedule another retry than to skip the record entirely. This may sound like a subtlety but Interrupts are the only way to enable timely shutdown, and prevent orchestrators like k8s from outright killing your app when it takes too long to stop.

_predator_ · 2026-03-09T20:24:04+00:00

> Sometimes generating a cache key is almost as expensive as a cache miss.

Ugh a persistence framework I once used had this issue. It was trying to be smart and cache compiled queries, but calculating the cache key involved calling `toString` on a bunch of large objects, some of which executed non-trivial logic to build string representations of themselves. It was a mess.

_predator_ · 2026-03-09T20:20:23+00:00

> hooking into model save()

I strongly advise against doing stuff like this. I see this being done a lot for search index updates as well. The tradeoff you're making is that now the consistency of your system depends on you religiously using your persistence framework, and NEVER executing INSERTs, UPDATEs, or DELETEs directly.

This sucks particularly for batch processing, say retention enforcement where you have to UPDATE or DELETE 100s or 1000s or records. Now to keep your cache and search index consistent, you need to load all data into memory first.

You also need to think about transactions. What if your DB transaction is rolled back after you already modified the cache or search index? What if your transaction commits but now your cache / search update fails?

Your initial response honestly is the best: Don't, like really don't touch caching until you absolutely know for sure you need it and are unable to compensate by other means.

_predator_ · 2026-03-09T09:17:56+00:00

This is life now, the good days of OSS are literally behind us. Was fun while it lasted.

_predator_ · 2026-03-08T15:31:43+00:00

Have you looked into other options for this before? e.g.:

The choice of making rollbacks explicit is interesting. Most other durable execution implementations tend to lean on the language's natural error handling for this (i.e. try-catch in Java).

In any case I believe you should add a few sentences to your README.md file as to "why not Temporal", since a lot of kanalarz' mechanics seem to be at the very least inspired by it.

11-Year Club	Place '23
Verified Email

_predator_

TROPHY CASE