> > 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.

Apologies, I may have misunderstood. If the new type is 100%
wire-compatible (recv/send) with the old fixed-length 6-byte type, then
there's no issue whatsoever.

Reply via email to