* Tom Lane <[EMAIL PROTECTED]> [001109 10:30]:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> >> Well, we need *some* way to extract a representation like "w.x.y.z/n".
> >> If you don't like text() as the name of that formatting function,
> >> suggest another name...
>
> > all_octets(cidr)::tex
Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> Well, we need *some* way to extract a representation like "w.x.y.z/n".
>> If you don't like text() as the name of that formatting function,
>> suggest another name...
> all_octets(cidr)::text maybe?
No, because that doesn't accurately describe what
* Peter Eisentraut <[EMAIL PROTECTED]> [001105 07:08]:
> Tom Lane writes:
>
> > Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > > A separate function for formatting output seems necessary, but
> > > if we don't reach an agreement though, it ought to work to cast
> > > CIDR to INET to get all fou
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> A separate function for formatting output seems necessary, but if we don't
> reach an agreement though, it ought to work to cast CIDR to INET to get
> all four octets, no?
Uh, weren't you one of the people objecting to relying on cidr-to-inet
casts t
* Alex Pilosov <[EMAIL PROTECTED]> [001103 20:47]:
> Agreed with all of it, but how about incorporating conversion from inet
> to int8? (first octet*256*256*256+second octet*256*256+third
> octet*256+fourth octet).
>
> This will allow to do a lot of magic with addresses using plain math.
>
> Al
Agreed with all of it, but how about incorporating conversion from inet
to int8? (first octet*256*256*256+second octet*256*256+third
octet*256+fourth octet).
This will allow to do a lot of magic with addresses using plain math.
Also, I'd still like netmask_length, length of netmask in bits.
-a
Works for me.
LER
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 (voice) Internet: [EMAIL PROTECTED]
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Larry Rosenman <[EMAIL PROTECTED]> writes:
> What was the final outcome?
I don't think we'd quite agreed what to do. The proposed code changes
are not large, we just need a consensus on what the behavior ought to
be.
Since a couple of people objected to the idea of using casts to control
the ou
* Larry Rosenman <[EMAIL PROTECTED]> [001028 02:23]:
> I don't think we need this ASAP for 7.1. Let's get the basic stuff
> working from a "least surprise" standpoint, and see what the user base
> comes up with. I really think your proposal from earlier tonite is
> the way to go, at least from m
On Fri, 27 Oct 2000, Alex Pilosov wrote:
> > BTW, does it strike anyone else as peculiar that the host(),
> > broadcast(), network(), and netmask() functions yield results
> > of type text, rather than type inet? Seems like it'd be considerably
> > more useful if they returned values of type ine
Tom Lane writes:
> Hm. I don't see any really good reason why host() rejects CIDR input
> in the first place. What's wrong with producing the host address
> that corresponds to extending the CIDR network address with zeroes?
Because it's semantically wrong. It's just as wrong as converting DA
On Fri, 27 Oct 2000, Tom Lane wrote:
> BTW, does it strike anyone else as peculiar that the host(),
> broadcast(), network(), and netmask() functions yield results
> of type text, rather than type inet? Seems like it'd be considerably
> more useful if they returned values of type inet with mask
On Fri, 27 Oct 2000, Tom Lane wrote:
> A more interesting question is whether the system needs to provide any
> assisting functions that aren't there now. The lookup function you guys
> are postulating seems like it would be (in the simple cases)
> create function my_network(inet) returns
e) have a function network(inet) which would look up the address in a
table of networks using longest-prefix-match. I.E. something similar to:
>> No need. Let the user do it themselves. Similar to what we did for
>> macaddr's back in the summer.
> Yeah, it can be user-defined (or a c
one more small request:
int8_inet(inet) and inet_int8(int8): functions to convert an inet to an
int8 and back. (not an int4, since postgres int4s are signed)
This allows me to do some additional manipulations on values. (ie. given a
host, determine its default gateway, for us, it is always first
* Tom Lane <[EMAIL PROTECTED]> [001027 17:54]:
> Alex Pilosov <[EMAIL PROTECTED]> writes:
> > On Fri, 27 Oct 2000, Tom Lane wrote:
> >> BTW, does it strike anyone else as peculiar that the host(),
> >> broadcast(), network(), and netmask() functions yield results
> >> of type text, rather than typ
* Alex Pilosov <[EMAIL PROTECTED]> [001027 21:20]:
> Please read below if the whole thing with inet/cidr doesn't make you puke
> yet ;) The semi-longish proposal is at the bottom.
>
> On Fri, 27 Oct 2000, Tom Lane wrote:
[snip]
> Actually, now that I think longer about the whole scheme in terms o
Larry Rosenman <[EMAIL PROTECTED]> writes:
> Fine, but host() rejects CIDR types right now
What's your point? network() doesn't behave the way you want right now,
either.
regards, tom lane
On Fri, 27 Oct 2000, Tom Lane wrote:
> BTW, does it strike anyone else as peculiar that the host(),
> broadcast(), network(), and netmask() functions yield results
> of type text, rather than type inet? Seems like it'd be considerably
> more useful if they returned values of type inet with maskl
I wrote:
> There is no subset type that corresponds to "valid host addresses
> only" --- if there were, it would be a subset of INET but would have
> no valid values in common with CIDR.
I take that back --- CIDR accepts w.x.y.z/32 for any w.x.y.z, which
would include valid host addresses. (But
Please read below if the whole thing with inet/cidr doesn't make you puke
yet ;) The semi-longish proposal is at the bottom.
On Fri, 27 Oct 2000, Tom Lane wrote:
> Alex Pilosov <[EMAIL PROTECTED]> writes:
> > We should have as much error-checking as possible.
>
> How so? Without a netmask you
On Fri, 27 Oct 2000, Larry Rosenman wrote:
> Not necessarily, especially for novices. Some people may want to
> store the netmask with the IP of a host (think ifconfig being
> AUTOGEN'd).
For a single host? Or for a network of hosts? But yes, I see your point if
a single host has x interfaces,
Alex Pilosov <[EMAIL PROTECTED]> writes:
> We should have as much error-checking as possible.
Only possible with a much tighter definition of what the intended use
of each type is. For example, you seem to be saying that broadcast
addresses aren't valid inet values, with which I do not agree unl
* Alex Pilosov <[EMAIL PROTECTED]> [001027 21:36]:
> On Fri, 27 Oct 2000, Larry Rosenman wrote:
>
> > Not necessarily, especially for novices. Some people may want to
> > store the netmask with the IP of a host (think ifconfig being
> > AUTOGEN'd).
> For a single host? Or for a network of hosts
Alex Pilosov <[EMAIL PROTECTED]> writes:
> On Fri, 27 Oct 2000, Tom Lane wrote:
>> BTW, does it strike anyone else as peculiar that the host(),
>> broadcast(), network(), and netmask() functions yield results
>> of type text, rather than type inet?
> I absolutely agree, except for network(), whic
* Tom Lane <[EMAIL PROTECTED]> [001027 21:53]:
> e) have a function network(inet) which would look up the address in a
> table of networks using longest-prefix-match. I.E. something similar to:
>
> >> No need. Let the user do it themselves. Similar to what we did for
> >> macaddr's bac
On Fri, 27 Oct 2000, Tom Lane wrote:
> Alex Pilosov <[EMAIL PROTECTED]> writes:
> > Also, I agree with Larry that cidr _must_ be printed with 4 octets in
> > them, whether they are 0 or not. (i.e. it should print 207.158.72.0/24)
>
> > This is the standard way of specifying addresses in all netw
Larry Rosenman <[EMAIL PROTECTED]> writes:
> I.E. for select network('207.158.72.0/24')
> I get
> 207.158.72.0
To my mind that should be done with host(), not network(). If you strip
the masklen information then what you have is no longer a network
specification, so expecting a function named n
* Tom Lane <[EMAIL PROTECTED]> [001027 17:41]:
> Larry Rosenman <[EMAIL PROTECTED]> writes:
> > Fine, but host() rejects CIDR types right now
>
> What's your point? network() doesn't behave the way you want right now,
> either.
Fine, network() can return CIDR (207.158.72/24), but allow host(
On Fri, 27 Oct 2000, Tom Lane wrote:
> The way I'm visualizing this, INET is a generalized type that will store
> any 4-octet address plus any netmask width from 1 to 32. This includes
> not only host addresses, but network specs and broadcast addresses.
> CIDR is a subset type that only accepts
* Tom Lane <[EMAIL PROTECTED]> [001027 17:04]:
> BTW, does it strike anyone else as peculiar that the host(),
> broadcast(), network(), and netmask() functions yield results
> of type text, rather than type inet? Seems like it'd be considerably
> more useful if they returned values of type inet w
* Tom Lane <[EMAIL PROTECTED]> [001027 17:29]:
> Larry Rosenman <[EMAIL PROTECTED]> writes:
> > I.E. for select network('207.158.72.0/24')
> > I get
> > 207.158.72.0
>
> To my mind that should be done with host(), not network(). If you strip
> the masklen information then what you have is no lo
BTW, does it strike anyone else as peculiar that the host(),
broadcast(), network(), and netmask() functions yield results
of type text, rather than type inet? Seems like it'd be considerably
more useful if they returned values of type inet with masklen = 32
(except for network(), which would kee
On Fri, 27 Oct 2000, Tom Lane wrote:
> Larry Rosenman <[EMAIL PROTECTED]> writes:
> > OK, what I really meant was a way to coerce a CIDR entity to INET so
> > that host() can work with a CIDR type to print all 4 octets.
>
> Hm. I don't see any really good reason why host() rejects CIDR input
I can't type today
- Forwarded message from Larry Rosenman <[EMAIL PROTECTED]> -
From: Larry Rosenman <[EMAIL PROTECTED]>
Subject: Re: [HACKERS] Summary: what to do about INET/CIDR
Date: Fri, 27 Oct 2000 15:09:36 -0500
Message-ID: <[EMAIL PROTECTED]>
User-Agent
* Tom Lane <[EMAIL PROTECTED]> [001027 15:14]:
> Alex Pilosov <[EMAIL PROTECTED]> writes:
> > Also, I agree with Larry that cidr _must_ be printed with 4 octets in
> > them, whether they are 0 or not. (i.e. it should print 207.158.72.0/24)
>
> > This is the standard way of specifying addresses in
Alex Pilosov <[EMAIL PROTECTED]> writes:
> Also, I agree with Larry that cidr _must_ be printed with 4 octets in
> them, whether they are 0 or not. (i.e. it should print 207.158.72.0/24)
> This is the standard way of specifying addresses in all network equipment.
> RFC specifies that, just the li
Larry Rosenman <[EMAIL PROTECTED]> writes:
> OK, what I really meant was a way to coerce a CIDR entity to INET so
> that host() can work with a CIDR type to print all 4 octets.
Hm. I don't see any really good reason why host() rejects CIDR input
in the first place. What's wrong with producing
On Fri, 27 Oct 2000, Larry Rosenman wrote:
> and network(cidr) should print ONLY the octets, not the mask...
Agreed. There's a function to get the mask size, and the network should
just return the network. Otherwise, it is impossible to use.
-alex
Tom Lane writes:
> 1. A data value like '10.1.2.3/16' is a legal INET value (it implies
> the host 10.1.2.3 in the network 10.1/16) but not a legal CIDR value.
> Hence, cidr_in should reject such a value. Up to now it hasn't.
Nod.
> 2. We do not have a datatype corresponding strictly to a ho
* Alex Pilosov <[EMAIL PROTECTED]> [001027 14:43]:
> On Fri, 27 Oct 2000, Larry Rosenman wrote:
> > ler=# select * from ler_test;
> > net | host
> > ---+--
> > 207.158.72/24 | 207.158.72.11/24
> > (1 row)
> >
> > ler=# select host(net::inet) from ler_
On Fri, 27 Oct 2000, Larry Rosenman wrote:
> ler=# select * from ler_test;
> net | host
> ---+--
> 207.158.72/24 | 207.158.72.11/24
> (1 row)
>
> ler=# select host(net::inet) from ler_test;
> ERROR: CIDR type has no host part
> ERROR: CIDR type has
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Inet is supposed to be host address, with optional network specification.
Agreed. As such, it probably should always display all 4 octets
regardless of the maskwidth. It doesn't do that at the moment:
regression=# select '127.0.0.1/8'::inet;
?col
* Tom Lane <[EMAIL PROTECTED]> [001027 09:49]:
> Larry Rosenman <[EMAIL PROTECTED]> writes:
> > Also a way to get network (.0) and broadcast (all ones) for a cidr
> > block out of our stuff.
>
> network() and broadcast() have been there all along ...
OK, what I really meant was a way to coerce a
* Larry Rosenman <[EMAIL PROTECTED]> [001027 11:08]:
> * Tom Lane <[EMAIL PROTECTED]> [001027 09:49]:
> > Larry Rosenman <[EMAIL PROTECTED]> writes:
> > > Also a way to get network (.0) and broadcast (all ones) for a cidr
> > > block out of our stuff.
> >
> > network() and broadcast() have been
* Larry Rosenman <[EMAIL PROTECTED]> [001027 09:51]:
> * Tom Lane <[EMAIL PROTECTED]> [001027 09:49]:
> > Larry Rosenman <[EMAIL PROTECTED]> writes:
> > > Also a way to get network (.0) and broadcast (all ones) for a cidr
> > > block out of our stuff.
> >
> > network() and broadcast() have been
* Tom Lane <[EMAIL PROTECTED]> [001027 09:49]:
> Larry Rosenman <[EMAIL PROTECTED]> writes:
> > Also a way to get network (.0) and broadcast (all ones) for a cidr
> > block out of our stuff.
>
> network() and broadcast() have been there all along ...
but don't work on CIDR types.
LER
>
>
Larry Rosenman <[EMAIL PROTECTED]> writes:
> Also a way to get network (.0) and broadcast (all ones) for a cidr
> block out of our stuff.
network() and broadcast() have been there all along ...
regards, tom lane
* Tom Lane <[EMAIL PROTECTED]> [001026 18:46]:
> After reviewing a number of past threads about the INET/CIDR mess,
> I have concluded that we should adopt the following behavior:
>
> 1. A data value like '10.1.2.3/16' is a legal INET value (it implies
> the host 10.1.2.3 in the network 10.1/16)
makes sense to me
On Thu, 26 Oct 2000, Tom Lane wrote:
> After reviewing a number of past threads about the INET/CIDR mess,
> I have concluded that we should adopt the following behavior:
>
> 1. A data value like '10.1.2.3/16' is a legal INET value (it implies
> the host 10.1.2.3 in the netwo
After reviewing a number of past threads about the INET/CIDR mess,
I have concluded that we should adopt the following behavior:
1. A data value like '10.1.2.3/16' is a legal INET value (it implies
the host 10.1.2.3 in the network 10.1/16) but not a legal CIDR value.
Hence, cidr_in should reject
51 matches
Mail list logo
