> 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
