Peter Eisentraut <peter.eisentr...@enterprisedb.com> writes:
> On 07.05.20 10:11, Erik Nordström wrote:
>> I am looking for feedback on the possibility of adding a table expansion
>> hook to PostgreSQL (see attached patch).
> Unlike the get_relation_info_hook, your proposed hook would *replace*
> expand_inherited_rtentry() rather than just tack on additional actions.
> That seems awfully fragile. Could you do with a hook that does
> additional things rather than replace a whole chunk of built-in code?
I suppose Erik is assuming that he could call expand_inherited_rtentry
(or better, the previous hook occupant) when his special case doesn't
apply. But I'm suspicious that he'd still end up duplicating large
chunks of optimizer/util/inherit.c in order to carry out the special
case, since almost all of that is private/static functions. It
does seem like a more narrowly-scoped hook might be better.
Would it be unreasonable of us to ask for a worked-out example making
use of the proposed hook? That'd go a long way towards resolving the
question of whether you can do anything useful without duplicating
lots of code.
I've also been wondering, given the table-AM projects that are
going on, whether we shouldn't refactor things to give partitioned
tables a special access method, and then shove most of the planner
and executor's hard-wired partitioning logic into access method
callbacks. That would make it a lot more feasible for extensions
to implement custom partitioning-like behavior ... or so I guess.
regards, tom lane
