Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2017-01-31 Thread Haribabu Kommi
On Tue, Jan 31, 2017 at 4:13 PM, Vitaly Burovoy wrote: > On 1/27/17, Haribabu Kommi wrote: > > Updated patches are attached. > > > Hello, > > I'm almost ready to mark it as Ready for committer. > The final round. Thanks for the review. >

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2017-01-30 Thread Michael Paquier
On Tue, Jan 31, 2017 at 2:13 PM, Vitaly Burovoy wrote: > I'm almost ready to mark it as Ready for committer. > The final round. Moved to next CF with same status, waiting on author as the last patch and the last review are very fresh. -- Michael -- Sent via

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2017-01-30 Thread Vitaly Burovoy
On 1/27/17, Haribabu Kommi wrote: > Updated patches are attached. Hello, I'm almost ready to mark it as Ready for committer. The final round. 1. >+DATA(insert OID = 774 ( macaddr8 ... >+#define MACADDR8OID 972 What does this number (972) mean? I think it should be

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2017-01-27 Thread Haribabu Kommi
On Fri, Jan 27, 2017 at 6:10 PM, Kuntal Ghosh wrote: > On Wed, Jan 25, 2017 at 6:00 PM, Haribabu Kommi > wrote: > > > Corrected as suggested. > > > > Updated patch attached. There is no change in the contrib patch. > Got whitspace error

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2017-01-27 Thread Haribabu Kommi
On Thu, Jan 26, 2017 at 9:42 PM, Vitaly Burovoy wrote: > On 1/25/17, Haribabu Kommi wrote: > > On Wed, Jan 25, 2017 at 6:43 PM, Vitaly Burovoy < > vitaly.buro...@gmail.com> > > wrote: > > > I'm going to do (I hope) a final review tonight. >

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2017-01-26 Thread Kuntal Ghosh
On Wed, Jan 25, 2017 at 6:00 PM, Haribabu Kommi wrote: > Corrected as suggested. > > Updated patch attached. There is no change in the contrib patch. Got whitspace error warning while applying contrib_macaddr8_1.patch:184. diff --git

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2017-01-26 Thread Vitaly Burovoy
On 1/25/17, Haribabu Kommi wrote: > On Wed, Jan 25, 2017 at 6:43 PM, Vitaly Burovoy > wrote: > >> On 1/23/17, Haribabu Kommi wrote: >> > The patch is split into two parts. >> > 1. Macaddr8 datatype support >> > 2.

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2017-01-25 Thread Haribabu Kommi
On Wed, Jan 25, 2017 at 6:43 PM, Vitaly Burovoy wrote: > On 1/23/17, Haribabu Kommi wrote: > > The patch is split into two parts. > > 1. Macaddr8 datatype support > > 2. Contrib module support. > > Hello, > > I'm sorry for the delay. > The

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2017-01-24 Thread Vitaly Burovoy
On 1/23/17, Haribabu Kommi wrote: > The patch is split into two parts. > 1. Macaddr8 datatype support > 2. Contrib module support. Hello, I'm sorry for the delay. The patch is almost done, but I have two requests since the last review. 1. src/backend/utils/adt/mac8.c:

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2017-01-23 Thread Haribabu Kommi
On Mon, Jan 23, 2017 at 6:29 PM, Kuntal Ghosh wrote: > On Thu, Jan 19, 2017 at 7:46 AM, Haribabu Kommi > wrote: > > > > Updated patch attached. > > > I've looked at the updated patch. There are still some changes that > needs to be done. It

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2017-01-22 Thread Kuntal Ghosh
On Thu, Jan 19, 2017 at 7:46 AM, Haribabu Kommi wrote: > > Updated patch attached. > I've looked at the updated patch. There are still some changes that needs to be done. It includes: 1. Adding macaddr8 support for btree_gist and testcases. 2. Implementation of macaddr8

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2017-01-18 Thread Haribabu Kommi
On Sat, Jan 14, 2017 at 6:28 PM, Kuntal Ghosh wrote: > On Mon, Jan 9, 2017 at 1:45 PM, Haribabu Kommi > wrote: > > Updated patch is attached. > > > I've a few comments about the patch. > Thanks for the review. + This type can accept

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2017-01-13 Thread Kuntal Ghosh
On Mon, Jan 9, 2017 at 1:45 PM, Haribabu Kommi wrote: > Updated patch is attached. > I've a few comments about the patch. + This type can accept both 6 and 8 bytes length MAC addresses. A 6 bytes length MAC address is internally converted to 8 bytes. We should

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2017-01-09 Thread Haribabu Kommi
On Fri, Jan 6, 2017 at 3:51 PM, Vitaly Burovoy wrote: > On 1/4/17, Haribabu Kommi wrote: > > On Tue, Nov 29, 2016 at 8:36 PM, Haribabu Kommi < > kommi.harib...@gmail.com> > > wrote: > >> Updated patch attached with added cast function from

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2017-01-05 Thread Vitaly Burovoy
On 1/4/17, Haribabu Kommi wrote: > On Tue, Nov 29, 2016 at 8:36 PM, Haribabu Kommi > wrote: >> Updated patch attached with added cast function from macaddr8 to >> macaddr. >> >> Currently there are no support for cross operators. Is this

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2017-01-04 Thread Haribabu Kommi
On Tue, Nov 29, 2016 at 8:36 PM, Haribabu Kommi wrote: > > > On Sat, Nov 26, 2016 at 4:48 PM, Tom Lane wrote: > >> Haribabu Kommi writes: >> > Currently the casting is supported from macaddr to macaddr8, but not the >> >

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-11-29 Thread Haribabu Kommi
On Sat, Nov 26, 2016 at 4:48 PM, Tom Lane wrote: > Haribabu Kommi writes: > > Currently the casting is supported from macaddr to macaddr8, but not the > > other way. This is because, not all 8 byte MAC addresses can be converted > > into 6 byte

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-11-25 Thread Tom Lane
Haribabu Kommi writes: > Currently the casting is supported from macaddr to macaddr8, but not the > other way. This is because, not all 8 byte MAC addresses can be converted > into 6 byte addresses. Well, yeah, so you'd throw an error if it can't be converted. This is

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-11-24 Thread Haribabu Kommi
On Wed, Nov 23, 2016 at 12:53 PM, Tom Lane wrote: > Haribabu Kommi writes: > > On Wed, Nov 23, 2016 at 1:42 AM, Tom Lane wrote: > >> The precedent of int4/int8/float4/float8 is that SQL data types should > >> be named after

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-11-22 Thread Tom Lane
Haribabu Kommi writes: > On Wed, Nov 23, 2016 at 1:42 AM, Tom Lane wrote: >> The precedent of int4/int8/float4/float8 is that SQL data types should >> be named after their length in bytes. So I'd be inclined to call this >> "macaddr8" not

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-11-22 Thread Haribabu Kommi
On Wed, Nov 23, 2016 at 1:42 AM, Tom Lane wrote: > Haribabu Kommi writes: > > Any suggestions for the name to be used for the new datatype the can > > work for both 48 and 64 bit MAC addresses? > > The precedent of int4/int8/float4/float8 is that

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-11-22 Thread Jon Nelson
On Tue, Nov 22, 2016 at 8:42 AM, Tom Lane wrote: > Haribabu Kommi writes: > > Any suggestions for the name to be used for the new datatype the can > > work for both 48 and 64 bit MAC addresses? > > The precedent of int4/int8/float4/float8 is that

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-11-22 Thread Tom Lane
Haribabu Kommi writes: > Any suggestions for the name to be used for the new datatype the can > work for both 48 and 64 bit MAC addresses? The precedent of int4/int8/float4/float8 is that SQL data types should be named after their length in bytes. So I'd be inclined to

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-11-21 Thread Haribabu Kommi
On Tue, Nov 22, 2016 at 5:33 AM, Robert Haas wrote: > On Sat, Nov 19, 2016 at 2:54 PM, Tom Lane wrote: > > Stephen Frost writes: > >> Let's create a new data type for this which supports old and new types, > >> add what casts make

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-11-21 Thread Robert Haas
On Sat, Nov 19, 2016 at 2:54 PM, Tom Lane wrote: > Stephen Frost writes: >> Let's create a new data type for this which supports old and new types, >> add what casts make sense, and call it a day. Changing the data type >> name out from under people is

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-11-19 Thread Tom Lane
Stephen Frost writes: > Let's create a new data type for this which supports old and new types, > add what casts make sense, and call it a day. Changing the data type > name out from under people is not helping anyone. +1. I do not think changing behavior for the existing

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-11-19 Thread Stephen Frost
* Shay Rojansky (r...@roji.org) wrote: > > > > > As I said before, Npgsql for one loads data types by name, not by OID. > >>> > So this would definitely cause breakage. > >>> > >>> Why would that cause breakage? > >> > >> Well, the first thing Npgsql does when it connects to a new database, is >

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-11-09 Thread Haribabu Kommi
On Fri, Nov 4, 2016 at 11:09 AM, Haribabu Kommi wrote: > > > On Tue, Oct 25, 2016 at 11:40 PM, Peter Eisentraut < > peter.eisentr...@2ndquadrant.com> wrote: > >> On 10/25/16 1:38 AM, Haribabu Kommi wrote: >> > Here I attached the first version of patch that supports

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-11-07 Thread Shay Rojansky
> > > As I said before, Npgsql for one loads data types by name, not by OID. >>> > So this would definitely cause breakage. >>> >>> Why would that cause breakage? >> >> >> Well, the first thing Npgsql does when it connects to a new database, is >> to query pg_type. The type names are used to

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-11-06 Thread Haribabu Kommi
On Mon, Nov 7, 2016 at 8:40 AM, Shay Rojansky wrote: > > 1. Does everyone agrees that renaming the existing datatype without >> > changing the OID? >> > >> > >> > As I said before, Npgsql for one loads data types by name, not by OID. >> > So this would definitely cause

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-11-06 Thread Shay Rojansky
> > > 1. Does everyone agrees that renaming the existing datatype without > > changing the OID? > > > > > > As I said before, Npgsql for one loads data types by name, not by OID. > > So this would definitely cause breakage. > > Why would that cause breakage? Well, the first thing Npgsql

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-11-04 Thread Peter Eisentraut
On 11/4/16 4:55 AM, Shay Rojansky wrote: > 1. Does everyone agrees that renaming the existing datatype without > changing the OID? > > > As I said before, Npgsql for one loads data types by name, not by OID. > So this would definitely cause breakage. Why would that cause breakage? --

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-11-04 Thread Shay Rojansky
> > Yes. Before doing this change, it is better to confirm the approach and > then do all the changes. > > 1. Does everyone agrees that renaming the existing datatype without > changing the OID? > As I said before, Npgsql for one loads data types by name, not by OID. So this would definitely

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-11-03 Thread Haribabu Kommi
On Tue, Oct 25, 2016 at 11:40 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 10/25/16 1:38 AM, Haribabu Kommi wrote: > > Here I attached the first version of patch that supports both EUI-48 and > > EUI-64 type > > Mac addresses with a single datatype called macaddr. This is

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-10-26 Thread Robert Haas
On Tue, Oct 18, 2016 at 7:25 PM, Bruce Momjian wrote: > On Wed, Oct 12, 2016 at 08:33:00AM -0400, Tom Lane wrote: >> As others have noted, there is no likelihood that we'd take a disk-format- >> compatibility-breaking patch for v10. Even if we wanted to do that, the >> above

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-10-25 Thread Peter Eisentraut
On 10/25/16 1:38 AM, Haribabu Kommi wrote: > Here I attached the first version of patch that supports both EUI-48 and > EUI-64 type > Mac addresses with a single datatype called macaddr. This is an variable > length > datatype similar like inet. It can store both 6 and 8 byte addresses. > Variable

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-10-24 Thread Haribabu Kommi
On Tue, Oct 18, 2016 at 1:51 AM, Shay Rojansky wrote: > The current macaddr datatype needs to be kept for some time by renaming >> it without changing OID and use the newer one for further usage. >> > > From the point of view of a driver maintainer... Npgsql looks up data > types

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-10-18 Thread Bruce Momjian
On Wed, Oct 12, 2016 at 08:33:00AM -0400, Tom Lane wrote: > As others have noted, there is no likelihood that we'd take a disk-format- > compatibility-breaking patch for v10. Even if we wanted to do that, the > above proposal would also break send/recv (binary COPY) compatibility for > macaddr. >

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-10-17 Thread Peter Eisentraut
On 10/12/16 4:59 PM, Tom Lane wrote: > The larger picture here is that we got very little thanks when we squeezed > IPv6 into the pre-existing inet datatype; there's a large number of people > who just said "no thanks" and started using the add-on ip4r type instead. I don't think that is a

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-10-17 Thread Shay Rojansky
> > The current macaddr datatype needs to be kept for some time by renaming > it without changing OID and use the newer one for further usage. > >From the point of view of a driver maintainer... Npgsql looks up data types by their name - upon first connection to a database it queries pg_type and

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-10-16 Thread Haribabu Kommi
On Thu, Oct 13, 2016 at 4:10 PM, Vitaly Burovoy wrote: > On 10/12/16, Tom Lane wrote: > >>> but we're > >>> not breaking on-disk compatibility of existing macaddr columns. > > Can I ask why? It will not be a varlen (typstorage will not be >

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-10-12 Thread Vitaly Burovoy
On 10/12/16, Tom Lane wrote: > Alvaro Herrera writes: >> Tom Lane wrote: >>> Vitaly Burovoy writes: P.S.: I still think it is a good idea to change storage format, >>> I'm not sure which part of "no" you didn't

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-10-12 Thread Haribabu Kommi
On Thu, Oct 13, 2016 at 7:59 AM, Tom Lane wrote: > Alvaro Herrera writes: > > Tom Lane wrote: > >> Vitaly Burovoy writes: > >>> P.S.: I still think it is a good idea to change storage format, > > >> I'm not sure which part

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-10-12 Thread Haribabu Kommi
On Thu, Oct 13, 2016 at 7:31 AM, Vitaly Burovoy wrote: > Haribabu Kommi, why have you read enough about EUI-64? > Your function "macaddr64_trunc" sets 4 lower bytes as 0 whereas > (according to the Wikipedia, but I can look for a standard) 3 bytes > are still define an

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-10-12 Thread Vitaly Burovoy
On 10/12/16, Tom Lane wrote: > Vitaly Burovoy writes: >> I'm sorry for the offtopic, but does anyone know a reason why a >> condition in mac.c > >>> if ((a < 0) || (a > 255) || (b < 0) || (b > 255) || >>> (c < 0) || (c > 255) || (d < 0) || (d >

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-10-12 Thread Tom Lane
Alvaro Herrera writes: > Tom Lane wrote: >> Vitaly Burovoy writes: >>> P.S.: I still think it is a good idea to change storage format, >> I'm not sure which part of "no" you didn't understand, but we're >> not breaking on-disk compatibility of

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-10-12 Thread Tom Lane
Vitaly Burovoy writes: > I'm sorry for the offtopic, but does anyone know a reason why a > condition in mac.c >> if ((a < 0) || (a > 255) || (b < 0) || (b > 255) || >> (c < 0) || (c > 255) || (d < 0) || (d > 255) || >> (e < 0) || (e > 255) || (f < 0) || (f > 255)) >

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-10-12 Thread Alvaro Herrera
Tom Lane wrote: > Vitaly Burovoy writes: > > P.S.: I still think it is a good idea to change storage format, > > I'm not sure which part of "no" you didn't understand, but we're > not breaking on-disk compatibility of existing macaddr columns. > Breaking the on-the-wire

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-10-12 Thread Tom Lane
Vitaly Burovoy writes: > P.S.: I still think it is a good idea to change storage format, I'm not sure which part of "no" you didn't understand, but we're not breaking on-disk compatibility of existing macaddr columns. Breaking the on-the-wire binary I/O representation

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-10-12 Thread Vitaly Burovoy
I'm sorry for the offtopic, but does anyone know a reason why a condition in mac.c > if ((a < 0) || (a > 255) || (b < 0) || (b > 255) || > (c < 0) || (c > 255) || (d < 0) || (d > 255) || > (e < 0) || (e > 255) || (f < 0) || (f > 255)) can not be rewritten as: > if (((a | b | c | d | e |

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-10-12 Thread Vitaly Burovoy
On 10/12/16, Vitaly Burovoy wrote: > On 10/12/16, Alvaro Herrera wrote: >> Julien Rouhaud wrote: >>> On 12/10/2016 14:32, Alvaro Herrera wrote: >>> > Julien Rouhaud wrote: >>> > >>> >> and you can instead make macaddr64 support both format, and

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-10-12 Thread Vitaly Burovoy
On 10/12/16, Alvaro Herrera wrote: > Julien Rouhaud wrote: >> On 12/10/2016 14:32, Alvaro Herrera wrote: >> > Julien Rouhaud wrote: >> > >> >> and you can instead make macaddr64 support both format, and provide a >> >> macaddr::macaddr64 cast >> > >> > Having macaddr64

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-10-12 Thread Alvaro Herrera
Julien Rouhaud wrote: > On 12/10/2016 14:32, Alvaro Herrera wrote: > > Julien Rouhaud wrote: > > > >> and you can instead make macaddr64 support both format, and provide a > >> macaddr::macaddr64 cast > > > > Having macaddr64 support both formats sounds nice, but how does it work? > > Will we

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-10-12 Thread Julien Rouhaud
On 12/10/2016 14:32, Alvaro Herrera wrote: > Julien Rouhaud wrote: > >> and you can instead make macaddr64 support both format, and provide a >> macaddr::macaddr64 cast > > Having macaddr64 support both formats sounds nice, but how does it work? > Will we have to reserve one additional bit to

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-10-12 Thread Tom Lane
Haribabu Kommi writes: > Here I attached a POC patch that adds the support for EUI-64 MAC address > storage with a new datatype macaddr64. Currently this type takes only > EUI-64 datatype, not accepts 48 bit MAC address. Our other data types that have sizes in the names

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-10-12 Thread Alvaro Herrera
Julien Rouhaud wrote: > and you can instead make macaddr64 support both format, and provide a > macaddr::macaddr64 cast Having macaddr64 support both formats sounds nice, but how does it work? Will we have to reserve one additional bit to select the representation? That would make the type be 65

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-10-12 Thread Julien Rouhaud
On 12/10/2016 09:32, Craig Ringer wrote: > On 12 October 2016 at 14:30, Haribabu Kommi wrote: > >> As we are moving to PostgreSQL 10, so are there any plans of backward >> compatiblity >> breakage, so the existing macaddr datatype itself can be changed to support >>

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-10-12 Thread Craig Ringer
On 12 October 2016 at 14:30, Haribabu Kommi wrote: > As we are moving to PostgreSQL 10, so are there any plans of backward > compatiblity > breakage, so the existing macaddr datatype itself can be changed to support > both > 48 and 64 bit MAC addresses. If not, I will

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-10-12 Thread Michael Paquier
On Wed, Oct 12, 2016 at 3:30 PM, Haribabu Kommi wrote: > As we are moving to PostgreSQL 10, so are there any plans of backward > compatiblity > breakage, so the existing macaddr datatype itself can be changed to support > both > 48 and 64 bit MAC addresses. Er, I had