Should escapeStringConn explicitly look for a zero byte and error?

[brandon-leapyear]

Just got bitten by a property test that tried to save a string with a zero byte in it to the database + got it silently truncated. I know that's the documented behavior in libpq, but it seems less than ideal in Haskell, a language that can contain zero bytes in strings unlike C.

Or perhaps it should be documented in escapeStringConn to look at the libpq docs for edge cases? In this case, should the postgresql-simple library throw an error? I'd understand postgresql-libpq not wanting to deviate from libpq behavior, but it seems like a good thing to catch unexpected behavior in postgresql-simple (I only bring it up because it seems like the authors of the two libraries are the same)

[phadej]

Note that VARCHAR and TEXT fields cannot contain null bytes in PostgreSQL.

• https://stackoverflow.com/questions/28813409/are-null-bytes-allowed-in-unicode-strings-in-postgresql-via-python
• https://www.postgresql.org/docs/current/datatype-character.html

The characters that can be stored in any of these data types are determined by the database character set, which is selected when the database is created. Regardless of the specific character set, the character with code zero (sometimes called NUL) cannot be stored. For more information refer to Section 24.3.

I really don't know what's the best option. One option is to throw an exception if there is zero byte in the argument to escapeStringConn as AFAIK it won't work anyway, but then we'll traverse most bytestrings for no reason.
Probably we just should document the truncation on zero byte, and outsource the problem to postgresql-simple (not that I have any idea atm, how to elegantly solve it there. ToField is expected to succeed for "all" inputs).