| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Beena Emerson <memissemerson(at)gmail(dot)com> |
| Cc: | Jeevan Ladhe <jeevan(dot)ladhe(at)enterprisedb(dot)com>, Rahila Syed <rahilasyed90(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Default Partition for Range |
| Date: | 2017-08-04 14:18:45 |
| Message-ID: | CA+TgmoZ-8_pj=OTmF6+B9stM8Z5HBbrv6OvDO_Gp_1-hhO8G3A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Jul 31, 2017 at 8:28 AM, Beena Emerson <memissemerson(at)gmail(dot)com> wrote:
> Thanks for informing.
> PFA the updated patch.
> I have changed the numbering of enum PartitionRangeDatumKind since I
> have to include DEFAULT as well. If you have better ideas, let me
> know.
Why do we need to introduce PARTITION_RANGE_DATUM_DEFAULT at all? It
seems to me that the handling of default range partitions ought to be
similar to the way a null-accepting list partition is handled -
namely, it wouldn't show up in the "datums" or "kind" array at all,
instead just showing up in PartitionBoundInfoData's default_index
field.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2017-08-04 14:27:17 | Re: Cache lookup errors with functions manipulation object addresses |
| Previous Message | Amit Kapila | 2017-08-04 13:44:01 | Re: Page Scan Mode in Hash Index |