From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> |
Cc: | Julien Rouhaud <rjuju123(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Mention ordered datums in PartitionBoundInfoData comment |
Date: | 2017-12-07 18:55:52 |
Message-ID: | CA+Tgmoa0nxTn5hcH34CVqMFtt4nNbE=sFR2TEpH8oGhm9DYRrg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Dec 5, 2017 at 1:03 AM, Ashutosh Bapat
<ashutosh(dot)bapat(at)enterprisedb(dot)com> wrote:
> Sorry. Thanks for pointing it out. fixed in the attached patch.
+ * The datums in datums array are arranged in the increasing order defined by
Suggest: in increasing order as defined
There's a second place where the same change is needed.
+ * resp. For range and list partitions this simply means that the datums in the
I think you should spell out "respectively" instead of abbreviating to "resp".
+ * datums array are arranged in the increasing order defined by the partition
+ * key collation.
It's not just the collation but also, and I think more importantly,
the operator class. And there can be multiple columns, and thus
multiple opclases/collations. Maybe "defined by the partition key's
operator classes and collations".
+ * PartitionBoundInfoData structures for two partitioned tables with exactly
+ * same bounds look exactly same.
This doesn't seem to me to add much.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-12-07 18:56:22 | Re: Speeding up pg_upgrade |
Previous Message | Tom Lane | 2017-12-07 18:52:21 | Re: Speeding up pg_upgrade |