Adding a type for json and jsonb columns

[CrowdHailer]

I need to add a json function for inserting json to the database.

I'm assuming the best thing to do is to add a function like pgo.int

e.g.

let args = [pgo.int(value), pgo.json(data)]

I would need to add a dependency on gleam_json to get a JSON type. is this acceptable?
I guess the other option would be to work with dynamic

[lpil]

What type would the pgo.json function take here? I do not want to add a dep on any specific JSON library as we don't yet have any that have been thoroughly designed.

This could also be a function in another library while we work out a more long-term API here.

[ghivert]

I think we could now add dep to gleam/json no?

---

If someone wonders how to support Json types from gleam_json, you could simply turn the JSON value in string, and it's working perfectly.

value
|> json.to_string()
|> pgo.text()

[lpil]

I suspect you don't even need to do that, the iodata representation might be supported by pgo.

Sounds like we don't need to do anything then as we can already supply JSON strings. Thanks all

[ghivert]

I suspect you don't even need to do that, the iodata representation might be supported by pgo.

Yes, but the only way to put a Json value without using some ugly coercion is by turning it in string, before using pgo.text, or am I missing something?

[lpil]

That's how JSON works, I'm not sure why you think it's ugly.

[ghivert]

My bad, I was unclear. I meant, it could be cool to have a native function to like pgo.json: fn(Json) -> Value. This could ensures you're not putting a String where you want to put a Json (because not all strings are valid JSON). It's more about type-safety. It ensures you're putting a JSON in the DB, and the compiler could help you on that one, not waiting for the SQL transaction to reject saying "incorrect argument".

Pushing json as string is perfectly fine for me.

[lpil]

Let's do that after the migration to OTP27 is done so we can drop the thoas dep in gleam_json.