Re: Data types for IP address.

From: Gaini Rajeshwar <raja(dot)rajeshwar2006(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: John R Pierce <pierce(at)hogranch(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Data types for IP address.
Date: 2011-02-24 09:23:12
Message-ID: AANLkTikbj9-j14uQOOUdUxLTJPyPRpSnBko4fgmXRtFR@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, Feb 24, 2011 at 3:03 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> John R Pierce <pierce(at)hogranch(dot)com> writes:
> > On 02/23/11 4:44 AM, Stephane Bortzmeyer wrote:
> > *3. Start-End IP format :* 1.2.3.0-1.2.3.255
> >> You don't even need to program the conversion, it is already done:
> >>
> >> % netmask 1.2.3.0:1.2.3.255
> >> 1.2.3.0/24
>
> > yes, but what about 10.1.2.57-10.1.2.123 ? presumably valid in his
> > range system, and certainly NOT a valid CIDR range.
>

>
> The question is does he actually have a use-case for address ranges that
> don't correspond to legal CIDR ranges, but do nonetheless have an
> identifiable lower boundary, upper boundary, and no holes? And if so,
> what is it? The whole thing looked to me like somebody inventing
> requirements with little or no study of what they really needed.
>

I have customers who wanted to access application from different
locations without using login credentials every time. So they wanted to
register their ip addresses and have automated authentication for them. As
i don't know how their ip addresses definitely going to be, i am assuming
that they might have a ip address rage that is not a valid CIDR.

> regards, tom lane
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Gaini Rajeshwar 2011-02-24 09:24:46 Re: Data types for IP address.
Previous Message Aleksey Tsalolikhin 2011-02-24 05:46:15 Re: database is bigger after dump/restore - why? (60 GB to 109 GB)