On Thu, Aug 10, 2017 at 6:56 AM, Jeevan Ladhe
<jeevan.ladhe@enterprisedb.com> wrote:
>> This looks like a problem with the default list partitioning patch. I
>> think "true" is what we expect to see here in both cases.
>
> In case of list partition if there is only default partition, then there is
> no
> specific value set that can be excluded from default partition, so in
> such a case DEFAULT partition for a list partitioned table simply will
> not have any constraint on it, and hence while the describe output is
> printed it does not have any constraints to be printed.
>
> Whereas, in case of default partition for a range partitioned table, in
> get_qual_for_range() it creates true boolean expression if default is the
> only partition. Here is the relevent code from Beena's patch:
>
> + else /* default is the only partition */
> + result = list_make1(makeBoolConst(true, false));
>
> I think, it is unnecessary to create a constraint that is going to be always
> true. Instead, if we have no constraints we can avoid some extra cpu
> cycles which would otherwise be wasted in evaluating an expression
> that is going to be always true.
That's a reasonable argument. I'm not sure whether having no
partition constraint at all is likely to be a source of bugs, but
certainly, not needing to check it is appealing.
> Having said this, I see a point that in such a case we should have
> some neat meaningful content to be printed for "Partition constraint: ".
> I think we can address this when we construct describe output string.
>
> Some ideas that come to my mind are:
> Partition constraint: NIL
> Partition constraint: no constraints
> No partition constraint.
> Partition constraint: true
>
> Please let me know your thoughts.
I like "No partition constraint." of those options.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company