| From: | Beena Emerson <memissemerson(at)gmail(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(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-09 02:56:00 |
| Message-ID: | CAOG9ApESEAtQ2U3qPZYEutTUYxUhi-5DP00D_kSiJEFaAyvOmw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Aug 4, 2017 at 7:48 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Mon, Jul 31, 2017 at 8:28 AM, Beena Emerson <memissemerson(at)gmail(dot)com> wrote:
>
> 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.
>
I have updated the patch to make it similar to the way default/null is
handled in list partition, removing the PARTITION_RANGE_DATUM_DEFAULT.
This is to be applied over v24 patches shared by Jeevan [1] which
applies on commit id 5ff3d73813ebcc3ff80be77c30b458d728951036.
The RelationBuildPartitionDesc has been modified a lot, especially the
way all_bounds, ndatums and rbounds are set.
--
Beena Emerson
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| Attachment | Content-Type | Size |
|---|---|---|
| default_range_partition_v9.patch | application/octet-stream | 27.9 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2017-08-09 03:17:04 | Re: Possible issue with expanded object infrastructure on Postgres 9.6.1 |
| Previous Message | Tom Lane | 2017-08-09 02:48:15 | Re: Server crash (FailedAssertion) due to catcache refcount mis-handling |