Naming convention: snake_case vs. camelCase

This is a bit of a pedantic (breaking) issue that I found while writing up the OpenAPI spec: due to the naming convention of Postgres (snake_case), most of the fields in the API are also snake_case. It’d be more idiomatic to use camelCase.

There are also other minor issues that I found (mostly to do with types, e.g. string should be number), so we can do all that plus the OpenAPI stuff in one go. Probably not gonna eliminate all of such issues, but we can at least kaizen our way there.

[kiwicopple]

yeah it’s already used in prod so it will definitely break. The camel -> snake conversions will be safer because we aren’t using query params, but we are using response keys/objects.

at this point it’s probably less effort to be 100% camel

Probably not with the changes to production but regardless, we should prioritize the effort going forward over the effort now. Writing less code is always my number 1 concern, more than blindly following a convention.

My gut is snake_case is going to save us a mountain of effort going forward, but I’ll leave the final decision to you

_{Side note, I used to always write snake-camel converters between my PG database and my API. When I started using postgREST I stopped doing that and it actually made things conceptually simpler - camel = code, snake = database. Also reduced my LOC. This convention isn’t unheard of either, but not really necessary here.}

[soedirgo]

@wiesson I think this issue https://github.com/supabase/postgrest-js/issues/204 is more relevant.