uuid.Value []byte vs string

[danilobuerger]

Is there a particular reason why uuid.Value returns a string instead of a []byte?

[danhardman]

I assume it's just to make it readable when storing it in a database, else you'd be storing it as a blob.

[danilobuerger]

What if i want to store it as a 16 byte blob instead of a 36 byte string?

[danhardman]

Typically, UUIDs are used as a client provided value to reference some unique record. So you'll typically receive it as a string. It makes sense to store it as such to avoid having to do any type conversion

[danilobuerger]

It doesn't really matter how it is received as this library stores it in a 16 byte array. So even if I did receive it as a string from a client, it would then be a 16 byte array after calling FromString.

Point is: I can scan it from either a 16 byte slice, a text byte slice or a string. When valuing it, I should have the same options. If it came from the database as a 16 byte slice, I would assume being able to put it back like that.

[danhardman]

Fair point. I was worried manually querying blob data in a MySQL database for example would be fiddly but it seems MySQL will cast strings to binary in queries. Not sure about other databases though...

[danilobuerger]

Postgres handles this fine as well. You can exec / query with either string or byte array. On the console, it displays the UUID type as a string.

[satori]

@danilobuerger @danhardman See initial discussion in #5
I never tested since if lib/pq supports binary protocol.

[danilobuerger]

@satori Thanks for the link. Support for binary protocol in lib/pq was added here: lib/pq#357. It is a bit annoying to always call Bytes(). Maybe there is a better solution while providing backward compatibility for people relying on it to be a string?

[BourgeoisBear]

@danilobuerger What is the downside to just rolling your own struct composition and overriding Value()?