Re: macaddr 64 bit (EUI-64) datatype support - Mailing list pgsql-hackers
| From | Haribabu Kommi |
|---|---|
| Subject | Re: macaddr 64 bit (EUI-64) datatype support |
| Date | |
| Msg-id | CAJrrPGfnAAjTMCmnvHZeELd3Cp_Lhy-_b=dYrM4-nkbDTDZQ1g@mail.gmail.com Whole thread Raw |
| In response to | Re: macaddr 64 bit (EUI-64) datatype support (Vitaly Burovoy <vitaly.burovoy@gmail.com>) |
| Responses |
Re: macaddr 64 bit (EUI-64) datatype support
(Shay Rojansky <roji@roji.org>)
|
| List | pgsql-hackers |
On Thu, Oct 13, 2016 at 4:10 PM, Vitaly Burovoy <vitaly.burovoy@gmail.com> wrote:
On 10/12/16, Tom Lane <tgl@sss.pgh.pa.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
pgsql-hackers by date: