Wierd data in inet data type

[hh-h]

Hello! Thank you for your awesome job!

This code creates different values in table

await conn.execute("CREATE table test1 (id serial primary key, ip inet not null)")
ip = '10.78.243.196'
ip32 = '10.78.243.196/32'
await conn.execute("INSERT INTO test1 (ip) VALUES($1)", ip)
await conn.execute("INSERT INTO test1 (ip) VALUES($1)", '10.78.243.196')
await conn.execute("INSERT INTO test1 (ip) VALUES('10.78.243.196')")
await conn.execute("INSERT INTO test1 (ip) VALUES('10.78.243.196/32')")
await conn.execute("INSERT INTO test1 (ip) VALUES($1)", ip32) // Exception ValueError: '10.78.243.196/32' does not appear to be an IPv4 or IPv6 address

 id | ip
----+-----------------
 1 | 10.78.243.196/0
 2 | 10.78.243.196/0
 3 | 10.78.243.196
 4 | 10.78.243.196
(3 rows)

I have latest version in pip asyncpg==0.6.3

 version
------------------------------------------------------------------------------------------
 PostgreSQL 9.5.3 on x86_64-pc-linux-gnu, compiled by gcc (Debian 4.9.2-10) 4.9.2, 64-bit

Could you please take a look?

[elprans]

Yea, ayncpg is currently (incorrectly) assumes that all inet columns are host addresses, but Postgres, in fact, allows network addresses there too. If you need to store network addresses, use the cidr type.

[hh-h]

Awesome, thank you!

[hatarist]

Sorry for posting in the existing issue, but the asyncpg 0.12.0 is still having a little bit of that problem.

The behaviour is still weird. The column has inet type:

CREATE TABLE test (ip inet, source text);

Example queries:

await pg.execute('INSERT INTO test (ip, source) VALUES ($1, $2);', '10.11.12.13', 'testip-string')
await pg.execute('INSERT INTO test (ip, source) VALUES ($1, $2);', ip_address('10.11.12.13'), 'testip-ipv4')
await pg.execute('INSERT INTO test (ip, source) VALUES ($1, $2);', ip_network('10.11.12.13'), 'testip-ipv4-net')

Which are, then, stored in the database like that:

=> SELECT ip, source FROM test;
 ip | source
----------------+-----------------
10.11.12.13/0 | testip-string
10.11.12.13/0 | testip-ipv4
10.11.12.13 | testip-ipv4-net

The strangest thing is that IPv4Network being applied to the single IP address actually sends it as I intended to send it, but as an IPv4Address.

Could anybody re-open the issue, please? I hope I'm not wrong here.

[hatarist]

Wow, thanks a lot! I confirm that it's sorted out, at least for the IPv4Address :)