On Sun, May 14, 2017 at 6:29 PM, Andres Freund <and...@anarazel.de> wrote: > On 2017-05-14 18:25:08 -0400, Tom Lane wrote: >> It may well be that we can get away with saying "we're not going >> to make it simple to move hash-partitioned tables with float >> partition keys between architectures with different float >> representations". But there's a whole lot of daylight between that >> and denying any support for float representations other than the >> currently-most-popular one. > > Note that I, IIRC in the mail you responded to, also argued that I don't > think it'd be a good idea to rely on hashfunctions being portable. The > amount of lock-in that'd create, especially for more complex datatypes, > seems wholly inadvisable. I still think that dumping tables in a way > they're reloaded via the top-partition (probably one copy statement for > each child partition), and prohibiting incoming fkeys to partitions, is > a better approach to all this.
You'd have to prohibit a heck of a lot more than that in order for this to work 100% reliably. You'd have to prohibit CHECK constraints, triggers, rules, RLS policies, and UNIQUE indexes, at the least. You might be able to convince me that some of those things are useless when applied to partitions, but wanting a CHECK constraint that applies to only one partition seems pretty reasonable (e.g. CHECK that records for older years are all in the 'inactive' state, or whatever). I think getting this to work 100% reliably in all cases would require an impractically large hammer. Now that's not to say that we shouldn't have a reload-through-the-top-parent switch; actually, I think that's a good idea. I just don't believe that it can ever be a complete substitute for portable hash functions. I think almost everybody here agrees that it isn't necessary to have hash functions that are 100% portable, e.g. to VAX. But it would be nice IMHO if you could use an integer column as the partitioning key and have that be portable between Intel and POWER. -- 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