On Wed, May 17, 2017 at 11:51 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Wed, May 17, 2017 at 1:41 AM, Ashutosh Bapat > <ashutosh.ba...@enterprisedb.com> wrote: >>> Fixed in the attached version; used "hash partition remainder must be >>> greater than or equal to 0" instead. >> >> I would suggest "non-zero positive", since that's what we are using in >> the documentation. > > Well, that's not very good terminology, because zero is not a positive > number. Existing error messages seem to use phrasing such as "THING > must be a positive integer" when zero is not allowed or "THING must be > a non-negative integer" when zero is allowed. For examples, do git > grep errmsg.*positive or git grep errmsg.*negative.
Ok. We need to change all the usages in the documentation and in the comments to non-negative. The point is to use same phrases consistently. > >> In partition_bounds_equal(), please add comments explaining why is it safe to >> check just the indexes? May be we should add code under assertion to make >> sure >> that the datums are equal as well. The comment could be something >> like, "If two partitioned tables have different greatest moduli, their >> partition schemes don't match. If they have same greatest moduli, and >> all remainders have different indexes, they all have same modulus >> specified and the partitions are ordered by remainders, thus indexes >> array will be an identity i.e. index[i] = i. If the partition >> corresponding to a given remainder exists, it will have same index >> entry for both partitioned tables or if it's missing it will be -1. >> Thus if indexes array matches, corresponding datums array matches. If >> there are multiple remainders corresponding to a given partition, >> their partitions are ordered by the lowest of the remainders, thus if >> indexes array matches, both of the tables have same indexes arrays, in >> both the tables remainders corresponding to multiple partitions all >> have same indexes and thus same modulus. Thus again if the indexes are >> same, datums are same.". > > That seems quite long. I have shared a patch containing a denser explanation with my last set of comments. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
