Design question: support CUD-operations with/without `RETURNING`

[kolemannix]

I love that the full row is returned by default. This is really useful and generally ideal. However, sometimes we just do not need it, and the JDBC -> case class decoding, as well as extra bandwidth used, is unnecessary.

It would be great to have an insert that does not return the row. The question is, should this insert support returning generated columns at all? I would say 'no' for simplicity; if you need returned generated values, call the regular insert.

As a workaround, we would just use insertUnsavedStreaming with a stream of 1 element, but we are not on Postgres 16 yet.

[oyvindberg]

Yeah, I'm very undecided on this - open for feedback.

As you can guess, it's easy to output more methods which are as similar as these would be.

So far I have tried to balance the generated code so that there is a certain signal/noise ratio because I like to check it in to track changes over time. Doubling the number of methods for returning/non-returning would affect that ratio, and it would take longer to compile more code.

So I've been wondering about this tradeoff, how much the extra encoding, decoding and transfer actually means. for most scales, I suspect it won't matter much. do you have any data to help make the decision? for instance how many inserts/second you can do with and without returning.

A thought would be to return a structure which would make you pick what to return, for instance repo.insertReturning(row).nothing.

[kolemannix]

I do not, unfortunately. My argument comes more from a migration perspective where the status-quo is that we are not returning the data, and migrating to typo means now returning the data, in a mature production system we'd feel far better if we knew we could achieve parity w/ existing queries.

I understand and hadn't considered the size of the codegen tradeoff. I don't believe the cost of another method is really so much, especially if its implementation re-uses the primary insert query. Returning a structure is definitely a way to keep the method count down though. But it introduces a typo type in the mix of the non-dsl runtime code, as a mini-dsl (referring to the .nothing idea)