Обсуждение: 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, Pennsylvania19026
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
entitledto 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
> 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, Pennsylvania19026
> 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. 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, Pennsylvania19026
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.
> 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);CREATEtest=> insert into test values ('1.2.3.4','1.2.3.4');INSERT 18474
1test=>insert into test values ('1.2.3.4/32','1.2.3.4/32');INSERT 18475 1test=> insert into test values
('1.2.3.4/24','1.2.3.4/24');INSERT18476 1test=> 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,
Pennsylvania19026
> 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, Pennsylvania19026
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,
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, Pennsylvania19026
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
ASsb, 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.