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