On Tue, Sep 16, 2014 at 2:07 PM, Peter Eisentraut <pete...@gmx.net> wrote: > It seems to me that this is a more general problem that can affect any > data type that relies on anything external. For example, you could > probably create a case where indexes are corrupted if you have two > different time zone databases. Or what if you use PostGIS and one of > the libraries it uses has different rounding behaviors in different > versions?
The timezone case you highlight here seems quite distinct from what Matthew is talking about, because in point of fact the on-disk representation is merely *interpreted* with reference to the timezone database. So, you could have an inconsistency between standbys concerning what the time was in a particular timezone at a particular timestamp value as reported by the timestamptz output function, but both standbys would be correct on their own terms, which isn't too bad. You still cannot have a situation where on a single standby, a value isn't returned by an index scan that patently exists in the table on the same standby (i.e. index corruption); the timezone isn't actually stored (just an offset from a special Postgres epoch). As for the PostGIS example, I think that they'd know better than to change the behavior of an established opclass B-Tree support function 1. If people that author opclasses don't read the documentation on how to do so correctly, what chance do regular DBAs have? Should they make sure that operator classes are authored correctly in each and every instance? Surely not. Even if I was wrong about all of this, we should treat text as a special case, a case worth making every effort for. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
