[PATCHES] IPv6 Support for INET/CIDR types.
Bruce Momjian
> > > Seems this will have to wait for 7.3.
> >
> > Why?
>
> because i didn't get it fixed in time.
>
> > and, to be a bit more riendly to those of us stuck on 56k lines, could you
> > avoid re-sending, repeatedly, large patch files?
>
> sorry.
Paul, do you have an updated patch that can be applied to 7.3?
--
Bruce Momjian | http://candle.pha.pa.us
pg...@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
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majo...@postgresql.org so that your
message can get through to the mailing list cleanly
Bruce Momjian
OK, I have forwarded my saved emails to Paul. Paul, there was great
confusion over how these data types show display addresses and masks,
and a compromise was hammered out that we are reluctant to throw out.
I wish our email archives where searchable online and I could point you
to the issues. Can someone summarize the issues, specifically how did
we change what Paul originally gave us so it can be done again? All I
have for detail is this from Tom Lane:
The patch as given reverts the I/O behavior of the inet datatypes
to what it originally was, rather than the compromise behavior that
was hammered out at great length before 7.1. (I'd give a link to
those discussions if fts.postgresql.org were working :-()
Seems the archives were down back then in October too. :-(
---------------------------------------------------------------------------
Paul Vixie wrote:
> here's the problem. i want to replace the inet_{net_}{ntop,pton}
> functions in postgres with the real ones from bind. however, your
> versions have been patched. so before i can replace them i need
> to understand exactly what you've patched and move that logic to
> the part of postgres that calls these functions. then i can import
> the real versions, which include vadim's ipv6 logic. then i can
> work on changing postgres to use the new ipv6 logic in these functions.
>
> any help with that first step would be appreciated.
>
> > From: Bruce Momjian <pg...@candle.pha.pa.us>
> > Message-Id: <200202221810...@candle.pha.pa.us>
> > Subject: Re: [PATCHES] IPv6 Support for INET/CIDR types.
> > In-Reply-To: <200110161420...@as.vix.com>
> > To: Paul A Vixie <pa...@vix.com>
> > Date: Fri, 22 Feb 2002 13:10:06 -0500 (EST)
> > Cc: "Marc G. Fournier" <scr...@hub.org>,
> > Vadim Kogan <va...@xcf.berkeley.edu>, pgsql-...@postgresql.org
> > X-Mailer: ELM [version 2.4ME+ PL96 (25)]
> > MIME-Version: 1.0
> > Content-Transfer-Encoding: 7bit
> > Content-Type: text/plain; charset=US-ASCII
> >
> > Paul A Vixie wrote:
> > > > > Seems this will have to wait for 7.3.
> > > >
> > > > Why?
> > >
> > > because i didn't get it fixed in time.
> > >
> > > > and, to be a bit more riendly to those of us stuck on 56k lines, could you
> > > > avoid re-sending, repeatedly, large patch files?
> > >
> > > sorry.
> >
> > Paul, do you have an updated patch that can be applied to 7.3?
> >
> > --
> > Bruce Momjian | http://candle.pha.pa.us
> > pg...@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
>
>
--
Bruce Momjian | http://candle.pha.pa.us
pg...@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
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
Bruce Momjian
Checking application/pgp-signature: FAILURE
-- Start of PGP signed section.
> Ok. I've been a little bit out of the loop lately.
>
> a) The original changes I had were made out of two parts:
> - inet_*_* part
> - postgres-specific part
> b) I have made some choices there as to how to show/input things.
> Basically, any valid representation is understood. The output
> is as close as possible to the similar IPv4 outputs. Also, the
> the most compact version is used (but that's in inet_*_*).
>
> If somebody has my original patches (WITH postgres-specific stuff), that'd
> probably be a good starting point. In any case, I will try to produce
> another diff today or sometime during this weekend. I will omit any changes
> to inet_*_*, since bind now has proper version (and moreover, that version
> is not the same as mine, since Paul rewrote some of the stuff).
Vadim, I just sent over the patch Paul submitted. Is that it? If not,
was your patch ever applied to the PostgreSQL CVS? If so, I can find it
using cvs diff -c and send it to you. Do you remember a rough date or
release?
--
Bruce Momjian | http://candle.pha.pa.us
pg...@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
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majo...@postgresql.org
Bruce Momjian
> > Vadim, I just sent over the patch Paul submitted. Is that it? If not,
> > was your patch ever applied to the PostgreSQL CVS? If so, I can find it
> > using cvs diff -c and send it to you. Do you remember a rough date or
> > release?
>
> changes to the BIND library code have been accepted by BIND, and we
> should find a way to use it there.
I knew the patch shouldn't be applied. I was just trying to give Vadim
what he needed. I am not even sure if I succeeded.
--
Bruce Momjian | http://candle.pha.pa.us
pg...@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
---------------------------(end of broadcast)---------------------------
Bruce Momjian
> > I don't believe the original patch ever made it into anything.
>
> vadim's original patch was the basis for BIND's ipv6 support in the
> set of functions that pgsql borrows from BIND. so, it did make it
> into _something_ just not the modified pgsql mirrors of these functions.
>
> my proposal is that we do away with the modified pgsql mirrors of these
> functions and teach the INET and CIDR handlers to "wrap" the BIND functions
> in a way that modifies the presentation format to be postgres-compatible.
> that way postgres can import new versions of, or use LIBC versions of,
> the BIND functions without having to worry about local modifications to them.
Are we sure the Bind library versions are going to be on all the OS's we
support?
Bruce Momjian
> > > my proposal is that we do away with the modified pgsql mirrors of these
> > > functions and teach the INET and CIDR handlers to "wrap" the BIND functions
> > > in a way that modifies the presentation format to be postgres-compatible.
> > > that way postgres can import new versions of, or use LIBC versions of,
> > > the BIND functions without having to worry about local modifications to them.
> >
> > Are we sure the Bind library versions are going to be on all the OS's we
> > support?
>
> and that's why "./configure" has to learn how to choose whether to use the
> system supplied versions or the internal bootstrapping versions.
Oh, I get it. I am on the same planet now. :-)
--
Bruce Momjian | http://candle.pha.pa.us
pg...@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
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majo...@postgresql.org)
Larry Rosenman
>
> OK, I have forwarded my saved emails to Paul. Paul, there was great
> confusion over how these data types show display addresses and masks,
> and a compromise was hammered out that we are reluctant to throw out.
>
> I wish our email archives where searchable online and I could point you
> to the issues. Can someone summarize the issues, specifically how did
> we change what Paul originally gave us so it can be done again? All I
> have for detail is this from Tom Lane:
>
> The patch as given reverts the I/O behavior of the inet datatypes
> to what it originally was, rather than the compromise behavior that
> was hammered out at great length before 7.1. (I'd give a link to
> those discussions if fts.postgresql.org were working :-()
>
> Seems the archives were down back then in October too. :-(
for the change was to ALWAYS print ALL 4 octets of an IPv4 address in
the default case.
You (Paul) were part of that discussion. I was one of the instigators
of it.
LER
> > > --
> > > Bruce Momjian | http://candle.pha.pa.us
> > > pg...@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
> >
> >
>
> --
> Bruce Momjian | http://candle.pha.pa.us
> pg...@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
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: l...@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749