Re: macaddr 64 bit (EUI-64) datatype support
Haribabu Kommi <kommi.haribabu@gmail.com>
From: Haribabu Kommi <kommi.haribabu@gmail.com>
To: Shay Rojansky <roji@roji.org>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Vitaly Burovoy <vitaly.burovoy@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Alvaro Herrera <alvherre@2ndquadrant.com>,
Julien Rouhaud <julien.rouhaud@dalibo.com>, Craig Ringer <craig@2ndquadrant.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2016-11-07T02:40:34Z
Lists: pgsql-hackers
On Mon, Nov 7, 2016 at 8:40 AM, Shay Rojansky <roji@roji.org> 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? > > > Well, the first thing Npgsql does when it connects to a new database, is > to query pg_type. The type names are used to associate entries with type > handlers, avoiding the hard-coding of OIDs in code. So if the type name > "macaddr" suddenly has a new meaning and its wire representation is > different breakage will occur. It is possible to release new versions of > Npgsql which will look at the PostgreSQL version and say "we know that in > PostgreSQL < 10 macaddr means this, but in >= 10 it means that". But that > doesn't seem like a good solution, plus old versions of Npgsql from before > this change won't work. > The new datatype that is going to replace the existing one works with both 6 and 8 byte MAC address and stores it a variable length format. This doesn't change the wire format. I don't see any problem with the existing applications. The new datatype can recv and send 8 byte MAC address also. Regards, Hari Babu Fujitsu Australia
Commits
-
Add support for EUI-64 MAC addresses as macaddr8
- c7a9fa399d55 10.0 landed
-
perltidy pg_dump TAP tests
- 6af8b89adba1 10.0 cited