From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
Cc: | Erik Nordström <erik(at)timescale(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Feedback on table expansion hook (including patch) |
Date: | 2021-03-06 18:09:10 |
Message-ID: | 1570777.1615054150@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2021-03-06 18:09:25 | Re: Some regular-expression performance hacking |
Previous Message | Magnus Hagander | 2021-03-06 17:56:49 | Re: pg_stat_statements oddity with track = all |