It checks for 'TRUE', 't', 'true', 'y', 'yes', 'on', and '1', and assumes anything else is false. This seems like overkill for interpreting fields from the server to me, since PostgreSQL only sends 't' and 'f' as text representations… but it’s not the right way to parse booleans in general the way PostgreSQL would either, since the latter
is case-insensitive ('True' is valid)
ignores surrounding whitespace (E' yes\t\n\f\r' is valid)
allows prefixes of words ('of', 'tru', 'fals' are valid)
In other words, there are strings PostgreSQL will parse as true that parseBool will parse as false with no warning.
So is 't' → true, 'f' → false, otherwise → throw a good direction? I’ll take a look at how it affects the performance of pg at some point.
Take the boolean parser, for example: https://github.com/brianc/node-pg-types/blob/fbe5b0e8888c8c842f6ebdc518f92bac5e62115b/lib/textParsers.js#L14-L23
It checks for
'TRUE'
,'t'
,'true'
,'y'
,'yes'
,'on'
, and'1'
, and assumes anything else isfalse
. This seems like overkill for interpreting fields from the server to me, since PostgreSQL only sends't'
and'f'
as text representations… but it’s not the right way to parse booleans in general the way PostgreSQL would either, since the latter'True'
is valid)E' yes\t\n\f\r'
is valid)'of'
,'tru'
,'fals'
are valid)In other words, there are strings PostgreSQL will parse as
true
thatparseBool
will parse asfalse
with no warning.So is
't'
→true
,'f'
→false
, otherwise → throw a good direction? I’ll take a look at how it affects the performance of pg at some point.