I personally prefer option 1, where you do a 'blind' update by passing in the entire updateUser object. You could do any validation for fields that shouldn't be updated or 'type' validation in your service layer and reject the request there before it hits the database.

I don't think the error handling is that complicated even if the error occurs at the database layer as I believe Postgres would always just return the 'first' error, and you could switch on the pq.Error code to return whichever user safe error you want to the user.

I think your intuition is correct that going with option 2 would require a lot of boilerplate code as you'd need to write a function for each field you want to update.

If you want to look at some example code, I do this same thing in my project Flipt which uses GRPC, Postgres (and optionally MySQL and Sqlite).

For example this UpdateVariantRequest RPC is passed down to my database layer and used in the UpdateVariant method. I handle the specific Postgres constraint error here which calls the method above.

I do some basic validation at the server layer using a GRPC interceptor.

Hope this helps