Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix use of ipaddress for INET types with netmask using ip_interface #74

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

commonism
Copy link

This patch addresses #71 and #66 and includes updated driver tests as requested in #71.

@jwp
Copy link
Contributor

jwp commented Jun 14, 2015

http://www.postgresql.org/docs/9.1/static/datatype-net-types.html#8.9.1; inet represents an address. I'm skeptical that the interface type is appropriate. I'm willing to commit a patch that provides a proper netmask for inet's so that text casts do not render a netmask along with the IP. I thought that was what the conversation about.

@commonism
Copy link
Author

inet represents an address which accepts values with nonzero bits to the right of the netmask.
The corresponding type -if you want to use ipaddress.* for inet- in python3 is IPvXInterface.

You would not try to map a signed int to a unsigned int, it would be obvious the types won't match.
Thats why I used IPvXInterface, it shares IPvXAddress as baseclass, but adds the ability of having a netmask with bits set to the right.
If the address is "qualified" - as in there is no netmask (v4/32 & v6/128) it returns IPvXAddress - as before.

The changes proposed in #71 do no fix the actual problem. Assume you have imported inet data into your postgres db, inet with nonzero bits to the right of the mask, like 10.0.0.1/24, this data can be a route, the router with the netmask.
Using current fe it is not possible to retrieve this data from the database properly as IPvXAddress does not qualify to cover the specifics of inet. Using the changes proposed in #71 does not change this at all. You still can not retrieve the data from the database which is in there.

@jwp
Copy link
Contributor

jwp commented Jun 15, 2015

I was going to dismiss this, but I see the inet_in allows a netmask to be specified... I don't remember that being the case before.

@jwp
Copy link
Contributor

jwp commented Jun 16, 2015

Wow, glossed over the documentation and missed the whole optional subnet part(my mind has been far away from the driver lately =\ ). Looking at ipaddress docs, IPvXInterface seems appropriate. However, I should note that the data is still accessible with the current version of the driver, you just have to go through a text cast to get it "select '...'::inet::text".

@commonism
Copy link
Author

Can we merge then?

@jwp
Copy link
Contributor

jwp commented Jun 16, 2015

Yes, I believe so.

@Deedasmi
Copy link

Any word on this?

@commonism
Copy link
Author

While I do not see why this is not getting merged, this workaround allows me to use the driver with INET types having a mask:

def patch_postgres_fe():
	import ipaddress
	import postgresql.types.io
	import postgresql.types.io.lib as lib
	from postgresql.types import INETOID
	m = postgresql.types.io.load('pg_network')
	

	def iface_inet_pack(ob, pack = lib.net_pack, Constructor = ipaddress.ip_interface):
		a = Constructor(ob)
		return pack((a.version, a.network.prefixlen, a.packed))

	def iface_inet_unpack(data, unpack = lib.net_unpack, Constructor = ipaddress.ip_interface):
		version, mask, data = unpack(data)
		if (version == 4 and mask == 32) or (version == 6 and mask == 128):
			return ipaddress.ip_address(data)
		else:
			return Constructor("{addr}/{mask}".format(addr=ipaddress.ip_address(data), mask=mask))

#	m.inet_pack = iface_inet_pack
#	m.inet_unpack = iface_inet_unpack

	m.oid_to_io[INETOID] = (iface_inet_pack, iface_inet_unpack, str)
	return m

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants