On Wed, Aug 24, 2022 at 2:59 AM Nikita Malakhov <huku...@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