public inbox for [email protected]
help / color / mirror / Atom feedFrom: Pavel Borisov <[email protected]>
To: Alexander Korotkov <[email protected]>
Cc: Japin Li <[email protected]>
Cc: Mark Dilger <[email protected]>
Cc: [email protected]
Subject: Re: Table AM Interface Enhancements
Date: Thu, 28 Mar 2024 17:12:20 +0400
Message-ID: <CALT9ZEH+8XWxCVcjf7Hm0eH+z7-TrvHOxnr7ndscDSA90T+2cQ@mail.gmail.com> (raw)
In-Reply-To: <CALT9ZEGNiQH57Edrdk7LRdbMQ3spc_8pQ1auem1BjphKH5z=4A@mail.gmail.com>
References: <CAPpHfdurb9ycV8udYqM=o0sPS66PJ4RCBM1g-bBpvzUfogY0EA@mail.gmail.com>
<[email protected]>
<CAPpHfdv0g30VPKBwK=jCEmDdybgdu2Ro8VSNbLnc22C6qKsaZA@mail.gmail.com>
<[email protected]>
<CAPpHfduNh1iTo1KGBLAWBBt6MZQ00YkSVvUPgFDp6vUKY5Qo8w@mail.gmail.com>
<CAPpHfduey2T2jebBzUiVAVivyNjRQ22EH_K=F6VCozB=f13tzQ@mail.gmail.com>
<CALT9ZEF5i_bhrtUhM4bR5uFFk-aCXsWYAWSrv0FAELXuFYk2Lw@mail.gmail.com>
<CAPpHfdvkessZ_Nj8O6o+PxfrZjVpESkhcBKT1HHjMezB1_zFWg@mail.gmail.com>
<ME3P282MB3166E42AEB15A41E6EBADC67B62C2@ME3P282MB3166.AUSP282.PROD.OUTLOOK.COM>
<CAPpHfduSX=7sEP7yp_ecsjaBDogXfHgXZ75Mg802r9XoJLxJLQ@mail.gmail.com>
<CALT9ZEHLPS8ZJVH4MyszsH_-quxPgH_rh7ZuaVYiedHx_tnzqA@mail.gmail.com>
<CALT9ZEHNeagO5PLb4Nv9J_ZaCtp+ArdVmbSLc0RHUzx_RPAa4w@mail.gmail.com>
<CALT9ZEFVRmQfFrawTnHNCRxY1Nc+gV-wbZKrCKO4H9kA0i-8tg@mail.gmail.com>
<CAPpHfdv6fDMkVZyJKuoaYdg5+zVnRNU6dMRM9m4mBH6+4W89ig@mail.gmail.com>
<CALT9ZEFb0yVmZ_OQACFhYDEP3OSo4BPAMk9kju2Ap274D6SqJg@mail.gmail.com>
<CAPpHfduE-Uk=E4W7DMyPpEeBHays-U+VzvrMgLbcEvX=ZKOiww@mail.gmail.com>
<CALT9ZEGNiQH57Edrdk7LRdbMQ3spc_8pQ1auem1BjphKH5z=4A@mail.gmail.com>
Hi, Alexander!
The other extensibility that seems quite clear and uncontroversial to me is
0006.
It simply shifts the decision on whether tuple inserts should invoke
inserts to the related indices to the table am level. It doesn't change the
current heap insert behavior so it's safe for the existing heap access
method. But new table access methods could redefine this (only for tables
created with these am's) and make index inserts independently
of ExecInsertIndexTuples inside their own implementations of
tuple_insert/tuple_multi_insert methods.
I'd propose changing the comment:
1405 * This function sets `*insert_indexes` to true if expects caller to
return
1406 * the relevant index tuples. If `*insert_indexes` is set to false,
then
1407 * this function cares about indexes itself.
in the following way
Tableam implementation of tuple_insert should set `*insert_indexes` to true
if it expects the caller to insert the relevant index tuples (as in heap
implementation). It should set `*insert_indexes` to false if it cares
about index inserts itself and doesn't want the caller to do index inserts.
Maybe, a commit message is also better to reformulate to describe better
who should do what.
I think, with rebase and correction in the comments/commit message patch
0006 is ready to be committed.
Regards,
Pavel Borisov.
view thread (22+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Table AM Interface Enhancements
In-Reply-To: <CALT9ZEH+8XWxCVcjf7Hm0eH+z7-TrvHOxnr7ndscDSA90T+2cQ@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox