On Thu, Aug 10, 2017 at 6:56 AM, Jeevan Ladhe <jeevan.la...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
