You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently we allow encoding any Text value, including ones that contain '\NUL', via ToField.
This is a theoretical issue because PG actually doesn't allow strings to contain the 0 code point, meaning that we can end up having a valid Text value which is not actually storable in PG - described in the end of this section of the manual
It is also a practical issue because generating text via Arbitrary easily leads to Text with '\NUL\ in it, meaning that we can't use Arbitrary Text out of the box to run some property tests which do insertion into PG.
Is there some way to improve this situation?
There could potentially be a newtype wrapper over Text which only allows for Texts which don't contain '\NUL', but that still means users have to write their own Arbitrary, since (I assume) this library won't depend on QuickCheck and the like. This will at least solve the theoretical concern of trying to insert a Text with '\NUL' in it and seeing it fail, if the ordinary Text instance gets gradually phased out (which there's no easy way to do right now at the moment, afaik).
The text was updated successfully, but these errors were encountered:
googleson78
changed the title
Solution for Text potentially containing '\NUL'
Solution for Text values potentially containing '\NUL'
Jan 4, 2024
Currently we allow encoding any
Text
value, including ones that contain'\NUL'
, viaToField
.This is a theoretical issue because PG actually doesn't allow strings to contain the 0 code point, meaning that we can end up having a valid
Text
value which is not actually storable in PG - described in the end of this section of the manualIt is also a practical issue because generating text via
Arbitrary
easily leads toText
with'\NUL\
in it, meaning that we can't useArbitrary Text
out of the box to run some property tests which do insertion into PG.Is there some way to improve this situation?
There could potentially be a newtype wrapper over
Text
which only allows forText
s which don't contain'\NUL'
, but that still means users have to write their ownArbitrary
, since (I assume) this library won't depend onQuickCheck
and the like. This will at least solve the theoretical concern of trying to insert aText
with'\NUL'
in it and seeing it fail, if the ordinaryText
instance gets gradually phased out (which there's no easy way to do right now at the moment, afaik).The text was updated successfully, but these errors were encountered: