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 CAJrrPGdDWw0OXFGh_E_1Vxxn1g8AgVKk-aLmnfOyTpxoXnqvrA@mail.gmail.com
Whole thread Raw
In response to Re: macaddr 64 bit (EUI-64) datatype support  (Shay Rojansky <roji@roji.org>)
Responses Re: macaddr 64 bit (EUI-64) datatype support  (Shay Rojansky <roji@roji.org>)
List 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

pgsql-hackers by date:

Previous
From: Etsuro Fujita
Date:
Subject: Re: Typo in comment in contrib/postgres_fdw/deparse.c
Next
From: Haribabu Kommi
Date:
Subject: Re: pg_hba_file_settings view patch