On Wed, Jul 19, 2017 at 3:26 PM, Mark Dilger <hornschnor...@gmail.com> wrote: >> Typically, when you try to store an out-of-range value in PostgreSQL, >> you get an ERROR, and that's one of the selling points of PostgreSQL. >> PostgreSQL users regularly beat up other projects for, say, allowing >> 0000-00-00 to be considered a valid date, or any similar perceived >> laxity in enforcing data consistency. I don't like the idea that we >> can just deviate from that principle whenever adhering to it is too >> much work. > > I don't see the relevance of this statement. I am not planning to allow > abstime data that is outside the range of the new epoch. Attempts to > cast strings like '1962-07-07 01:02:03' to abstime would draw an > exception with a suitably informative message. > > Now, the objection to having on-disk data automagically change meaning > is concerning, ...
I see those things as very similar issues, but YMMV. > ... and I was particularly unsatisfied with the idea that > NOSTART_ABSTIME and NOEND_ABSTIME would suddenly be > reinterpreted as seconds in the year 2068, which is why I made mention > of it upthread. I was less concerned with dates prior to 1970 being > reinterpreted, though it is hard to justify why that bothers me less. I think any change in the meaning of bytes already on disk is a concern. It wouldn't bother me to say "these are second-class types, so if you have columns of this type, pg_upgrade will fail and tell you that you can't upgrade a database with those columns from a catversion < X to a catversion > X". But having it silently work and silently corrupt your data doesn't seem OK to me. > Those who feel otherwise might like to also argue for dropping > float4 because float8 does all the same stuff better. I don't think that's the same thing, but given my notorious hatred of floating point arithmetic, it would also bother me less than you might think. -- 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