[mlarraz]

PostgreSQL prints IPv4-mapped (and the old IPv4-compatible) IPv6 addresses in dotted form, e.g. ::ffff:192.168.1.1/128. PG::TextDecoder::Inet can't decode those, so with PG::BasicTypeMapForResults the whole result fails:

conn = PG.connect
conn.type_map_for_results = PG::BasicTypeMapForResults.new(conn)
conn.exec("SELECT '::ffff:192.168.1.1'::inet").getvalue(0, 0)
# => TypeError: wrong data for text inet converter in tuple 0 field 0 val

The decoder picks the address family with strchr(val, '.') ? AF_INET : AF_INET6, so these values go to inet_pton(AF_INET, ...), which rejects them. The same happens for cidr (e.g. ::ffff:10.0.0.0/104). These addresses show up in columns that store client addresses, since a dual-stack socket reports IPv4 peers as ::ffff:a.b.c.d. Encoding the same IPAddr already works; only decoding fails.

This checks for ':' instead: IPv6 text always contains one and IPv4 text never does. I added a few mapped addresses to the existing inet and cidr cases in basic_type_map_for_results_spec.rb; they fail without the change and pass with it. The Windows branch of the decoder uses IPAddr.new and isn't touched, and host-bit masking (#353) is unchanged.

Reproduced with 1.5.4, 1.6.3 and master on macOS. The line dates back to when the decoder was added in 1.1.0.

I found this while reviewing the decoders with an AI assistant; I verified the repro and the fix myself.

[larskanis]

Thank you, this looks good!