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

Functions for calculate lower and high range of an IP address using a CIDR mask #5095

Merged
merged 11 commits into from
May 1, 2019

Conversation

YiuRULE
Copy link
Contributor

@YiuRULE YiuRULE commented Apr 24, 2019

I hereby agree to the terms of the CLA available at: https://yandex.ru/legal/cla/?lang=en

For changelog. Remove if this is non-significant change.

Category (leave one):

  • New Feature

Short description (up to few sentences):

Functions for calculate the lower range and an higher range for an IP using a CIDR, both for IPv4 and IPv6.

Detailed description (optional):

This two functions, named IPv4CIDRtoIPv4Range and IPv6CIDRtoIPv6Range take two arguments, an IP address (in IPv4 address for the IPv4 function, and in IPv6 address
for IPv6 function), and an UInt8 who correspond to the CIDR mask we want to apply.

An equivalent of IPv4CIDRtoIPv4Range(IPv4NumToString('192.168.0.0'), 16) can be interpreted as 192.168.0.0/16 using the CIDR notation.

It return a tuple containing two IPv4 for the IPv4 functions and a tuple containing two IPv6 for the IPv6, it contain for both the theorically the lowest and highest IP for the subnet.

This function can potentially use to know if an IP is part of a subnet, and also if we use the lowest or highest range to aggregate the IP by subnet.

A possible solution was posted on issue #247 for an IPv4 range (solution based also on the first post of the issue) using directly a query and using a bit shifting. But it wouldn't be possible for calculate an IPv6 subnet as Clickhouse stored IPv6 using a FixedString(16), who make the task a little bit difficult with doing a bit shifting on an array.

@geldot
Copy link
Contributor

geldot commented Apr 25, 2019

Would it make sense to return an (IPv4,IPv4) tuple rather than a (UInt32,UInt32) tuple? That would make the interface more intuitive for display/interactive use. Specific use cases can always cast to UInt32 afterwards if needed.

@YiuRULE
Copy link
Contributor Author

YiuRULE commented Apr 26, 2019

Thanks for the suggestion, now both function return a tuple with an IPv4 and IPv6!

@alexey-milovidov alexey-milovidov added the pr-feature Pull request with new product feature label May 1, 2019
@alexey-milovidov
Copy link
Member

Need to remove .FunctionsCoding.h.swo file.

@alexey-milovidov alexey-milovidov merged commit 2dccdb1 into ClickHouse:master May 1, 2019
alexey-milovidov added a commit that referenced this pull request May 1, 2019
@alexey-milovidov
Copy link
Member

IPv6CIDRtoIPv6Range -> IPv6CIDRToRange

String getName() const override { return name; }

size_t getNumberOfArguments() const override { return 2; }
bool isInjective(const Block &) override { return true; }
Copy link
Member

@alexey-milovidov alexey-milovidov May 1, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It isn't.

@alexey-milovidov
Copy link
Member

Missing performance test.

@alexey-milovidov
Copy link
Member

I will fix all the remaining issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pr-feature Pull request with new product feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants