On Wed, Aug 24, 2022 at 2:59 AM Nikita Malakhov <hukutoc@gmail.com> wrote:
> I've rebased actual branch onto the latest master and re-created patches. Checked with git am,
> all applied correctly. Please check the attached patches.
> Rebased branch resides here:
> https://github.com/postgrespro/postgres/tree/toasterapi_clean
I tried installing and using the dummy_toaster that's provided with
the gitlink. Upgrade of that cluster fails with the following message:
pg_restore: creating TOASTER "dummy_toaster"
pg_restore: while PROCESSING TOC:
pg_restore: from TOC entry 2044; 9861 16390 TOASTER dummy_toaster (no owner)
pg_restore: error: could not execute query: ERROR: unrecognized
or unsupported class OID: 9861
Command was: CREATE TOASTER "dummy_toaster" HANDLER
"public"."dummy_toaster_handler";
I was looking through the thread for a more in-depth description of
the "vtable" concept, but I didn't see one. It looks like it's just an
arbitrary extension point, and any new additions would require surgery
on whatever function needs the particular magic provided by the
toaster. E.g. your bytea-append toaster extension in the gitlink,
which still has to modify byteacat() in varlena.c to implement a very
specific optimization, and then declares its support for that
hardcoded optimization in the extension.
I'm skeptical that this would remain coherent as it grows. The patch
claims the vtable API is "powerful", which... I suppose it is, if you
get to make arbitrary modifications to the core whenever you implement
it. Did you already have thoughts about which operations would belong
under that umbrella? What would the procedure be for adding
functionality to that API? What happens if a toaster wants to
implement two magic performance optimizations instead of one?
--Jacob
