Re: Feedback on table expansion hook (including patch)

On Sat, Mar 06, 2021 at 01:09:10PM -0500, Tom Lane wrote:
> Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)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