Re: macaddr 64 bit (EUI-64) datatype support

On Thu, Oct 13, 2016 at 4:10 PM, Vitaly Burovoy <vitaly(dot)burovoy(at)gmail(dot)com>
wrote:

> On 10/12/16, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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
> changed), it just changes typlen to 8 and typalign to 'd'.
> For every major release 9.0, 9.1, 9.2 .. 9.6 the docs says "A
> dump/restore using pg_dumpall, or use of pg_upgrade, is required".
> Both handle changes in a storage format. Do they?
>

macaddr is not a varlena datatype, all the varlena datatypes stores the
length of the data in the header byte because of variable length data
they can hold.

As the macaddr datatype is not that type, so changing the storage size
from 6 to 8 will break the on-disk compatibility, thus it can cause users
to use only pg_dump to upgrade to version 10. pg_upgrade doesn't
handle the changes in storage format.

Just because of a single datatype, loosing the option of using pg_upgrade
is huge and it is not worth as I feel.

> >>> Breaking the on-the-wire binary I/O representation seems like a
> >>> nonstarter as well.
>
> I wrote that for the EUI-48 (MAC-48) values the binary I/O
> representation can be saved.
> The binary format (in DataRow message) has a length of the column
> value which is reflected in PGresAttValue.len in libpq.
> If the client works with the binary format it must consult with the
> length of the data.
> But until the client works with (and columns have) MAC-48 nothing
> hurts it and PGresAttValue.len is "6" as now.

By taking some steps, yes, it is possible to accept both 48-bit and 64-bit
address into a single macaddr datatype.

But I feel this should be done with a new datatype and eventually drop
the old datatype after some time.

> ===
> I see no type (besides integers, floats and related with them: their
> ranges and arrays ) where numbers appears indicating their capacity:
>
> postgres=# select typname from pg_type where typname ~ '[0-9]' and
> typname not like 'pg_toast_%';
> typname
> -------------
> int8
> int2
> int2vector
> int4
> float4
> float8
> _int2
> _int2vector
> _int4
> _int8
> _float4
> _float8
> int4range
> _int4range
> int8range
> _int8range
> (16 rows)
>
> So why should we have the name "macaddr" without capacity number and
> (unexpectedly) macaddr8 (when a different number appears in the
> official name "EAI-64")?
>
> ===
> I offer a change when the current behavior is not changed for MAC-48
> values at all (for textual and binary I/O), internal representation is
> always 64bit long, and input and output are mapped from (and when it
> is possible to) MAC-48 to seamless usage of a "mac address" concept.
>

I agree that adding new datatype whenever the standards are changed to
store the MAC address, instead the new datatype that we are going to add
now can changed as an varlena datatype, so it can handle any length mac
addresses.

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.

Regards,
Hari Babu
Fujitsu Australia