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

Wed, 21 Oct 1998 02:14:02 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
New INET and CIDR types
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.

Wed, 21 Oct 1998 07:12:43 -0400 (EDT)
darcy@druid.net (D'Arcy J.M. Cain)
Re: [HACKERS] New INET and CIDR types
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
==========================================================================




Wed, 21 Oct 1998 07:13:13 -0400 (EDT)
Vince Vielhaber <vev@michvhf.com>
Re: [HACKERS] New INET and CIDR types
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

Wed, 21 Oct 1998 10:25:55 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] New INET and CIDR types 
> 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 19026

Wed, 21 Oct 1998 11:42:18 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] New INET and CIDR types
> 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, Pennsylvania 19026

Wed, 21 Oct 1998 12:15:08 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] New INET and CIDR types
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.

Wed, 21 Oct 1998 12:33:14 -0400 (EDT)
darcy@druid.net (D'Arcy J.M. Cain)
Re: [HACKERS] New INET and CIDR types
> 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

Wed, 21 Oct 1998 13:12:43 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] New INET and CIDR types
> 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.

Wed, 21 Oct 1998 10:21:18 -0700
Paul A Vixie <paul@vix.com>
Re: [HACKERS] New INET and CIDR types 
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


Wed, 21 Oct 1998 14:43:21 -0400 (EDT)
"Marc G. Fournier" <scrappy@hub.org>
Re: [HACKERS] New INET and CIDR types
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.

Wed, 21 Oct 1998 22:03:53 -0400 (EDT)
darcy@druid.net (D'Arcy J.M. Cain)
Re: [HACKERS] New INET and CIDR types
> 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 19026

Wed, 21 Oct 1998 22:09:42 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] New INET and CIDR types
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.

Thu, 22 Oct 1998 09:57:16 -0400 (EDT)
darcy@druid.net (D'Arcy J.M. Cain)
Re: [HACKERS] New INET and CIDR types
> 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

Thu, 22 Oct 1998 10:17:45 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] New INET and CIDR types
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

Tue, 27 Oct 1998 19:58:58 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] New INET and CIDR types
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.

Wed, 28 Oct 1998 05:49:20 -0500 (EST)
darcy@druid.net (D'Arcy J.M. Cain)
Re: [HACKERS] New INET and CIDR types
> 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

Wed, 28 Oct 1998 15:19:30 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] New INET and CIDR types
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.

Thu, 29 Oct 1998 08:53:05 -0500 (EST)
darcy@druid.net (D'Arcy J.M. Cain)
Re: [HACKERS] New INET and CIDR types