Robert Haas <robertmh...@gmail.com> writes: > On Fri, May 12, 2017 at 1:12 PM, Andres Freund <and...@anarazel.de> wrote: >> Given that a lot of data types have a architecture dependent representation, >> it seems somewhat unrealistic and expensive to have a hard rule to keep them >> architecture agnostic. And if that's not guaranteed, then I'm doubtful it >> makes sense as a soft rule either.
> That's a good point, but the flip side is that, if we don't have such > a rule, a pg_dump of a hash-partitioned table on one architecture > might fail to restore on another architecture. Today, I believe that, > while the actual database cluster is architecture-dependent, a pg_dump > is architecture-independent. Is it OK to lose that property? I'd vote that it's not, which means that this whole approach to hash partitioning is unworkable. I agree with Andres that demanding hash functions produce architecture-independent values will not fly. Maintaining such a property for float8 (and the types that depend on it) might be possible if you believe that nobody ever uses anything but IEEE floats, but we've never allowed that as a hard assumption before. Even architecture dependence isn't the whole scope of the problem. Consider for example dumping a LATIN1-encoded database and trying to reload it into a UTF8-encoded database. People will certainly expect that to be possible, and do you want to guarantee that the hash of a text value is encoding-independent? regards, tom lane -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers