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 (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
