On Tue, Oct 18, 2016 at 7:25 PM, Bruce Momjian <bruce@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