On Tue, Oct 18, 2016 at 7:25 PM, Bruce Momjian <br...@momjian.us> wrote: > On Wed, Oct 12, 2016 at 08:33:00AM -0400, Tom Lane wrote: >> As others have noted, there is no likelihood that we'd take a disk-format- >> compatibility-breaking patch for v10. Even if we wanted to do that, the >> above proposal would also break send/recv (binary COPY) compatibility for >> macaddr. >> >> I think that probably the best bet here is to have two types and put some >> thought into making them interoperate where appropriate, as the various >> sizes of int do. It's kind of a shame that this won't look like the >> approach used for inet addresses, but we're stuck. > > If feels like we are going into VARCHAR2 territory where we end up > telling people to use an oddly-named data type forever. Some are > suggesting JSONB is in that category.
I think that's just the price of maintaining a stable database system over the course of many years. You end up with a few warts in the name of backward compatibility. It's not wonderful to have warts, but backward compatibility has enough value to make it worth enduring the warts. If the worst thing that happens is we end up with types called jsonb and macaddr8, we're doing well. Obviously, there's some point at which maintaining backward compatibility becomes too much of a nuisance to be worthwhile, and that's why we've periodically made compatibility breaks of various types. I'm sure we'll continue to do that in the future from time to time, but I wouldn't do it here. I think Tom's got the right idea: let's leave the existing datatype alone to avoid breaking things for people who are already using it, and add a new one for people to enable the new functionality. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
