New INET and CIDR types
I have recieved the files from D'Arcy for new INET and CIDR types. INET
is use for hosts, while CIDR for networks. No duplicate code. CIDR
behaves the same as INET, except for a different input function. The
system catalogs take care of the mapping of CIDR to INET functions.
It will require an initdb for beta users moving to 6.4 final. Is this
OK? If so, I will apply it tomorrow. If not, the type will have to be
disabled for 6.4.
The big question is how many people have _live_ data in 6.4 beta
databases, who don't want to initdb for 6.4 final, and can't use
pg_upgrade to move to 6.4 final.
If I don't hear any objections, I will do it some time around noon
tomorrow, EST.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Thus spake Bruce Momjian
I have recieved the files from D'Arcy for new INET and CIDR types. INET
is use for hosts, while CIDR for networks. No duplicate code. CIDR
behaves the same as INET, except for a different input function. The
system catalogs take care of the mapping of CIDR to INET functions.It will require an initdb for beta users moving to 6.4 final. Is this
OK? If so, I will apply it tomorrow. If not, the type will have to be
disabled for 6.4.
Just to clarify, what we have done (are doing) is to rename the existing
inet type as cidr. This means that the CIDR type is now for CIDRized
networks as Paul originally proposed. There are functions to extract the
various components such as netmask, broadcast address and mask length.
The INET type is now for either hosts or hosts plus networks. The
code is not quite perfect yet but it compiles and works if you enter
a host as x.x.x.x/32. We'll try to improve it before 6.4 but at
least the catalogues are set up so we can fine tune the type without
doing an initdb or changing the user API.
Between 6.4 and 6.5 we'll work on improving the type. While the
catalogues won't change, we can modify the underlying code. The
decision, which we should really make now for the documentation,
is what type to make it. Remember that we identified 3 types, INET,
IHOST and CHOST. With the name change we can call the first one CIDR
now. The question is, what type should the new inet type represent,
IHOST or CHOST?
IHOST is meant to hold a host only. To specify a host and the
network information using IHOST would require also using CIDR.
CHOST is meant to hold a host and network information in the same
type. It can hold an IHOST by itself if desired. There are
functions to extract the various components such as host, netmask,
broadcast address and mask length.
As you have probably guessed, I vote for CHOST.
Paul, can you send me the new functions that you wrote? These will
be needed for the new type either way. Hopefully I can fold it in
before 6.4.
If I don't hear any objections, I will do it some time around noon
tomorrow, EST.
Of course, all of the above is assuming that everyone accepts this
change.
Bruce, I was thinking that since cidr.c consists of a single function
and it uses most of the code in inet.c anyway, why don't we just fold it
into inet.c instead of having a whole file for it?
This is almost as much work as my day job. And after 6.4 is released
I get to go through the same thing for the next release of PyGreSQL.
--
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.
On Wed, 21 Oct 1998, Bruce Momjian wrote:
It will require an initdb for beta users moving to 6.4 final. Is this
OK? If so, I will apply it tomorrow. If not, the type will have to be
disabled for 6.4.The big question is how many people have _live_ data in 6.4 beta
databases, who don't want to initdb for 6.4 final, and can't use
pg_upgrade to move to 6.4 final.
I do, but since this is my off season it's not a big deal. I usually
keep a backup database running on another machine anyway.
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null
# include <std/disclaimers.h> TEAM-OS2
Online Searchable Campground Listings http://www.camping-usa.com
"There is no outfit less entitled to lecture me about bloat
than the federal government" -- Tony Snow
==========================================================================
Bruce Momjian <maillist@candle.pha.pa.us> writes:
The big question is how many people have _live_ data in 6.4 beta
databases, who don't want to initdb for 6.4 final, and can't use
pg_upgrade to move to 6.4 final.
Hey, sounds like an opportunity for pg_upgrade to get some beta testing.
I know I haven't even touched it yet (I just initdb'd the last few
times), but I will try it for this if it will work for updating a
6.4beta database to the new state.
regards, tom lane
Import Notes
Reply to msg id not found: YourmessageofWed21Oct1998021402-0400199810210614.CAA28964@candle.pha.pa.us | Resolved by subject fallback
Thus spake Bruce Momjian
I have recieved the files from D'Arcy for new INET and CIDR types. INET
is use for hosts, while CIDR for networks. No duplicate code. CIDR
behaves the same as INET, except for a different input function. The
system catalogs take care of the mapping of CIDR to INET functions.It will require an initdb for beta users moving to 6.4 final. Is this
OK? If so, I will apply it tomorrow. If not, the type will have to be
disabled for 6.4.Just to clarify, what we have done (are doing) is to rename the existing
inet type as cidr. This means that the CIDR type is now for CIDRized
networks as Paul originally proposed. There are functions to extract the
various components such as netmask, broadcast address and mask length.
These functions also work for INET too.
The INET type is now for either hosts or hosts plus networks. The
code is not quite perfect yet but it compiles and works if you enter
a host as x.x.x.x/32. We'll try to improve it before 6.4 but at
least the catalogues are set up so we can fine tune the type without
doing an initdb or changing the user API.
We have to get it working OK in the next day, then any changes go into
post 6.4 minor releases. We have regression tests and can't be changing
things.
I would like the INET type to not display/require the /32 anymore.
Between 6.4 and 6.5 we'll work on improving the type. While the
catalogues won't change, we can modify the underlying code. The
decision, which we should really make now for the documentation,
is what type to make it. Remember that we identified 3 types, INET,
IHOST and CHOST. With the name change we can call the first one CIDR
now. The question is, what type should the new inet type represent,
IHOST or CHOST?IHOST is meant to hold a host only. To specify a host and the
network information using IHOST would require also using CIDR.CHOST is meant to hold a host and network information in the same
type. It can hold an IHOST by itself if desired. There are
functions to extract the various components such as host, netmask,
broadcast address and mask length.
People could just put a netmask in the field, so INET seems more
generic.
Functionality-wise, I like CHOST.
As you have probably guessed, I vote for CHOST.
Paul, can you send me the new functions that you wrote? These will
be needed for the new type either way. Hopefully I can fold it in
before 6.4.If I don't hear any objections, I will do it some time around noon
tomorrow, EST.Of course, all of the above is assuming that everyone accepts this
change.
No objections yet.
Bruce, I was thinking that since cidr.c consists of a single function
and it uses most of the code in inet.c anyway, why don't we just fold it
into inet.c instead of having a whole file for it?
OK.
This is almost as much work as my day job. And after 6.4 is released
I get to go through the same thing for the next release of PyGreSQL.
Join the club. It is usually _harder_ than my day job, but it is not as
often as my day job.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026Thus spake Bruce Momjian
I have recieved the files from D'Arcy for new INET and CIDR types. INET
is use for hosts, while CIDR for networks. No duplicate code. CIDR
behaves the same as INET, except for a different input function. The
system catalogs take care of the mapping of CIDR to INET functions.It will require an initdb for beta users moving to 6.4 final. Is this
OK? If so, I will apply it tomorrow. If not, the type will have to be
disabled for 6.4.
INET/CIDR changes applied.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026Thus spake Bruce Momjian
The INET type is now for either hosts or hosts plus networks. The
code is not quite perfect yet but it compiles and works if you enter
a host as x.x.x.x/32. We'll try to improve it before 6.4 but at
least the catalogues are set up so we can fine tune the type without
doing an initdb or changing the user API.We have to get it working OK in the next day, then any changes go into
post 6.4 minor releases. We have regression tests and can't be changing
things.
It does work. More importantly we have the catalogues and API nailed
down. There are some effeciencies and fine tuning that could be done
but I think what we have is good enough that documentation is now
more of a priority than code.
I would like the INET type to not display/require the /32 anymore.
That's done. The only thing is that now you have to manually put
the /32 on input. I'll fix that very soon.
Between 6.4 and 6.5 we'll work on improving the type. While the
catalogues won't change, we can modify the underlying code. The
decision, which we should really make now for the documentation,
is what type to make it. Remember that we identified 3 types, INET,
IHOST and CHOST. With the name change we can call the first one CIDR
now. The question is, what type should the new inet type represent,
IHOST or CHOST?IHOST is meant to hold a host only. To specify a host and the
network information using IHOST would require also using CIDR.CHOST is meant to hold a host and network information in the same
type. It can hold an IHOST by itself if desired. There are
functions to extract the various components such as host, netmask,
broadcast address and mask length.People could just put a netmask in the field, so INET seems more
generic.
They could. As I have said I wouldn't. If I had to store a netmask
alone I would store it as a masklen in an integer. To each his own
though. What we have gives maximum flexibility I think.
Functionality-wise, I like CHOST.
No one has objected so I will go forward on that basis.
Bruce, I was thinking that since cidr.c consists of a single function
and it uses most of the code in inet.c anyway, why don't we just fold it
into inet.c instead of having a whole file for it?OK.
Will you do it or shall I?
--
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.Thus spake Bruce Momjian
The INET type is now for either hosts or hosts plus networks. The
code is not quite perfect yet but it compiles and works if you enter
a host as x.x.x.x/32. We'll try to improve it before 6.4 but at
least the catalogues are set up so we can fine tune the type without
doing an initdb or changing the user API.We have to get it working OK in the next day, then any changes go into
post 6.4 minor releases. We have regression tests and can't be changing
things.It does work. More importantly we have the catalogues and API nailed
down. There are some effeciencies and fine tuning that could be done
but I think what we have is good enough that documentation is now
more of a priority than code.
OK. Yes, you can continue cleaning things up. I just want some
regression tests and documentation, and you can then continue, but I
hope they changes will not affect the contents of the documentation or
regression tests. If you can concentrate on those changes first, then
the docs/regression, that would be good.
I would like the INET type to not display/require the /32 anymore.
That's done. The only thing is that now you have to manually put
the /32 on input. I'll fix that very soon.
Actually, the /32 is not required. It properly displays it if it was
supplied, and supresses it if it is not.
In fact, it may be supressing the /32 when it should not, like in the
CIDR type:
test=> create table test (x inet, y cidr);
CREATE
test=> insert into test values ('1.2.3.4','1.2.3.4');
INSERT 18474 1
test=> insert into test values ('1.2.3.4/32','1.2.3.4/32');
INSERT 18475 1
test=> insert into test values ('1.2.3.4/24','1.2.3.4/24');
INSERT 18476 1
test=> select * from test;
x |y
--------+--------
1.2.3.4 |1.2.3.4
1.2.3.4 |1.2.3.4
1.2.3/24|1.2.3/24
(3 rows)
I would think the CIDR type should preserve the /32.
Between 6.4 and 6.5 we'll work on improving the type. While the
catalogues won't change, we can modify the underlying code. The
decision, which we should really make now for the documentation,
is what type to make it. Remember that we identified 3 types, INET,
IHOST and CHOST. With the name change we can call the first one CIDR
now. The question is, what type should the new inet type represent,
IHOST or CHOST?IHOST is meant to hold a host only. To specify a host and the
network information using IHOST would require also using CIDR.CHOST is meant to hold a host and network information in the same
type. It can hold an IHOST by itself if desired. There are
functions to extract the various components such as host, netmask,
broadcast address and mask length.People could just put a netmask in the field, so INET seems more
generic.They could. As I have said I wouldn't. If I had to store a netmask
alone I would store it as a masklen in an integer. To each his own
though. What we have gives maximum flexibility I think.
I can see cases where storing the netmask separately would be nice, and
it should display in a nice INET format.
Functionality-wise, I like CHOST.
No one has objected so I will go forward on that basis.
Good.
Bruce, I was thinking that since cidr.c consists of a single function
and it uses most of the code in inet.c anyway, why don't we just fold it
into inet.c instead of having a whole file for it?OK.
Will you do it or shall I?
Already done.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
I would think the CIDR type should preserve the /32.
Makes no difference. If all four octets are specified and no "/" is given,
the "/32" is assumed. Printing it would be nicer but not printing it is not
an error.
On Wed, 21 Oct 1998, Bruce Momjian wrote:
I have recieved the files from D'Arcy for new INET and CIDR types. INET
is use for hosts, while CIDR for networks. No duplicate code. CIDR
behaves the same as INET, except for a different input function. The
system catalogs take care of the mapping of CIDR to INET functions.It will require an initdb for beta users moving to 6.4 final. Is this
OK? If so, I will apply it tomorrow. If not, the type will have to be
disabled for 6.4.The big question is how many people have _live_ data in 6.4 beta
databases, who don't want to initdb for 6.4 final, and can't use
pg_upgrade to move to 6.4 final.If I don't hear any objections, I will do it some time around noon
tomorrow, EST.
Great...I'm going to plan for a BETA3 to be put out for Friday, so that
the testing broadens out a bit more...
Marc G. Fournier scrappy@hub.org
Systems Administrator @ hub.org
scrappy@{postgresql|isc}.org ICQ#7615664
Thus spake Bruce Momjian
It does work. More importantly we have the catalogues and API nailed
down. There are some effeciencies and fine tuning that could be done
but I think what we have is good enough that documentation is now
more of a priority than code.OK. Yes, you can continue cleaning things up. I just want some
regression tests and documentation, and you can then continue, but I
hope they changes will not affect the contents of the documentation or
regression tests. If you can concentrate on those changes first, then
the docs/regression, that would be good.
For sure not the documentation. As for the regression testing, it should
be final by Friday. Unfortunately I'm having problems. The last sup
seems to have broken the inet type. I'll try to get you in #PostgreSQL
and talk about this.
That's done. The only thing is that now you have to manually put
the /32 on input. I'll fix that very soon.Actually, the /32 is not required. It properly displays it if it was
supplied, and supresses it if it is not.
In certain cases. I now have the functions from Paul so I should be able
to get that correct tonight if I can get the type working again.
In fact, it may be supressing the /32 when it should not, like in the
CIDR type:
Again, will be fixed when I plug in Paul's functions.
I would think the CIDR type should preserve the /32.
Internally it does. Paul said it doesn't matter and I assume it is
his function leaving it off though I haven't checked.
--
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.Thus spake Bruce Momjian
It does work. More importantly we have the catalogues and API nailed
down. There are some effeciencies and fine tuning that could be done
but I think what we have is good enough that documentation is now
more of a priority than code.OK. Yes, you can continue cleaning things up. I just want some
regression tests and documentation, and you can then continue, but I
hope they changes will not affect the contents of the documentation or
regression tests. If you can concentrate on those changes first, then
the docs/regression, that would be good.For sure not the documentation. As for the regression testing, it should
be final by Friday. Unfortunately I'm having problems. The last sup
seems to have broken the inet type. I'll try to get you in #PostgreSQL
and talk about this.
Fixed.
Thomas will do all the markup. Just some info for the docs are needed.
He should provide you with what he needs.
That's done. The only thing is that now you have to manually put
the /32 on input. I'll fix that very soon.Actually, the /32 is not required. It properly displays it if it was
supplied, and supresses it if it is not.In certain cases. I now have the functions from Paul so I should be able
to get that correct tonight if I can get the type working again.
Great.
In fact, it may be supressing the /32 when it should not, like in the
CIDR type:Again, will be fixed when I plug in Paul's functions.
I would think the CIDR type should preserve the /32.
Internally it does. Paul said it doesn't matter and I assume it is
his function leaving it off though I haven't checked.
I recommend displaying the /32 for cidr. Paul says it is not required,
but would be 'nice', and I agree.
Sorry to be pressuring, but I want this off the Open Items list before
Marc has a coronary. His head swells badly, and turns all red. :-)
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026Thus spake Bruce Momjian
For sure not the documentation. As for the regression testing, it should
be final by Friday. Unfortunately I'm having problems. The last sup
seems to have broken the inet type. I'll try to get you in #PostgreSQL
and talk about this.Fixed.
Mostly. There seems to still be a problem with the network function as
I mentioned in the messages to patches. Also, as I mentionwed there,
the output of the functions should be left justified, not right. Also,
I think the netmasklen function should be called masklen. Given the
polymorphic nature of the type system and the fact that it is being
applied to inet or cidr types, I don't think there is any confusion
using the shorter, more familiar term.
Thomas will do all the markup. Just some info for the docs are needed.
He should provide you with what he needs.
I just received that. I'll get to work. I also have most of the queries
for the regression tests which I'll send along shortly.
Internally it does. Paul said it doesn't matter and I assume it is
his function leaving it off though I haven't checked.I recommend displaying the /32 for cidr. Paul says it is not required,
but would be 'nice', and I agree.
darcy=> select '1.2.3.4/32'::cidr;
?column?
----------
1.2.3.4/32
(1 row)
darcy=> select '1.2.3.4/32'::inet;
?column?
--------
1.2.3.4
(1 row)
Sorry to be pressuring, but I want this off the Open Items list before
Marc has a coronary. His head swells badly, and turns all red. :-)
Perhaps we should hand out plastic sheeting like at Gallagher concerts
just in case. :-)
--
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.Thus spake Bruce Momjian
For sure not the documentation. As for the regression testing, it should
be final by Friday. Unfortunately I'm having problems. The last sup
seems to have broken the inet type. I'll try to get you in #PostgreSQL
and talk about this.Fixed.
Mostly. There seems to still be a problem with the network function as
I mentioned in the messages to patches. Also, as I mentionwed there,
I can't find any network anything in inet.c.
the output of the functions should be left justified, not right. Also,
I think the netmasklen function should be called masklen. Given the
polymorphic nature of the type system and the fact that it is being
applied to inet or cidr types, I don't think there is any confusion
using the shorter, more familiar term.
Done.
Thomas will do all the markup. Just some info for the docs are needed.
He should provide you with what he needs.I just received that. I'll get to work. I also have most of the queries
for the regression tests which I'll send along shortly.
Great.
Internally it does. Paul said it doesn't matter and I assume it is
his function leaving it off though I haven't checked.I recommend displaying the /32 for cidr. Paul says it is not required,
but would be 'nice', and I agree.darcy=> select '1.2.3.4/32'::cidr;
?column?
----------
1.2.3.4/32
(1 row)darcy=> select '1.2.3.4/32'::inet;
?column?
--------
1.2.3.4
(1 row)
Nice.
Sorry to be pressuring, but I want this off the Open Items list before
Marc has a coronary. His head swells badly, and turns all red. :-)Perhaps we should hand out plastic sheeting like at Gallagher concerts
just in case. :-)
Yep.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
I've added in the inet/cidr types to the regression test, using mostly
the tests that D'Arcy sent. Just changed the layout a bit to conform to
the other tests and added a test or two to do equality comparisons.
D'Arcy et al, could you follow up and augment those tests, either now if
it's easy or for v6.5? Probably better to wait a bit as we learn more
about the types and their expected behaviors.
All regression tests pass on my Linux/i686 machine.
- Tom
Thus spake Thomas G. Lockhart
D'Arcy et al, could you follow up and augment those tests, either now if
it's easy or for v6.5? Probably better to wait a bit as we learn more
about the types and their expected behaviors.
What kind of things are you looking for? I thought I had most possibilities
covered in the tests I sent.
--
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.What kind of things are you looking for? I thought I had most
possibilities covered in the tests I sent.
The original test loaded a table and displayed the results. I'd like to
see some queries which exercise the operators associated with the types.
In this case, that may just be comparison operators, but if you have
math operators we should exercise those too. And any other conversion
operations, such as converting back and forth from int4, if that is
allowed.
So, things like (don't know if this exact example is sensible):
select '' as count, c as cidr from inet_tbl
where c < '128.149.50' and c > '128.149';
would be interesting.
- Tom
Thus spake Thomas G. Lockhart
So, things like (don't know if this exact example is sensible):
select '' as count, c as cidr from inet_tbl
where c < '128.149.50' and c > '128.149';
Of course. I only sent in tests for the functions I added. Ok, add
the following two INSERT statements.
INSERT INTO INET_TBL (c, i) VALUES ('10', '11.1.2.3/8');
INSERT INTO INET_TBL (c, i) VALUES ('10', '9.1.2.3/8');
Then add the following query.
SELECT i, c,
i < c AS lt, i <= c AS le, i = c AS eq,
i >= c AS ge, i > c AS gt, i <> c AS ne,
i << c AS sb, i <<= c AS sbe, i >> c AS sup, i >>= c AS spe
FROM INET_TBL;
--
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.