I think it makes sense to keep calling it a table because it has all the logical properties of a table even though it will differ from a regular table on the basis of physical implementation details such as that it does not own physical storage. Am I missing something? > > + <entry><structfield>partexprs</structfield></entry> > > There's a certain symmetry between this and what we do for indexes, > but I'm wondering whether there's a use case for partitioning a table > by an expression rather than a column value. I suppose if you've > already done the work, there's no harm in supporting it.
Yeah, it's not a whole lot of code to manage expressions alongside simple column references.
Users who would like to partition their tables by "age" will partition those by the month or year extracted out of a date column e.g. order_date. They will find it convenient to use an expression (extract(month from date)) as a partition key, instead of storing month or year as a separate column.
--
Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
