On Sun, May 14, 2017 at 8:00 PM, Bruce Momjian <br...@momjian.us> wrote: > Do we even know that floats are precise enough to determine the > partition. For example, if you have 6.000000001, is it possible for > that to be 5.9999999 on some systems? Are IEEE systems all the same for > these values? I would say we should disallow any approximate date type > for partitioning completely.
I'm inclined in this direction, as well. Hash partitioning is mostly useful for things that are likely to be join keys or group keys, and floats aren't. Same for complex user-defined types. The real problem here is what Tom pointed out: that we would have trouble hashing strings in an encoding-insensitive way. Strings are useful as join/group keys, so it would be painful to not support them. Perhaps there's some kind of compromise, like a pg_dump mode that reloads through the root. Or maybe hash partitions are really a "semi-logical" partitioning that the optimizer understands, but where things like per-partition check constraints don't make sense. Regards, Jeff Davis Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers