On Sat, Mar 06, 2021 at 01:09:10PM -0500, Tom Lane wrote: > 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.
That seems pretty reasonable. I suspect that that process will expose bits of the planning and execution machinery that have gotten less isolated than they should be. More generally, and I'll start a separate thread on this, we should be working up to including a reference implementation, however tiny, of every extension point we supply in order to ensure that our APIs are at a minimum reasonably usable and remain so. Best, David. -- David Fetter <david(at)fetter(dot)org> http://fetter.org/ Phone: +1 415 235 3778 Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
