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.
>
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
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
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
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.
>
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
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.
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
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:
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
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
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
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
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
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
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
>> >
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
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
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
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
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
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
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
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
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
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
* 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
>
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
>
> > 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
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
>
> > 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
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?
--
>
> 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
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
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
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
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
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.
>
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
>
> 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
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
>
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
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
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
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 >
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
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))
>
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
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
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 |
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
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
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
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
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
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
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
>>
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
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
59 matches
Mail list logo