On Tue, Jun 04, 2019 at 10:18:03AM -0400, Robert Haas wrote: > On Sat, Jun 1, 2019 at 3:09 PM Michael Paquier <mich...@paquier.xyz> wrote: >> I am fine to live with the dependency with vacuum.h as it is not that >> strange. However for BulkInsertState we get a hard dependency with a >> heap-related area and it seems to me that we had better move that part >> out of heapam.c, as we want a clear dependency cut with the heap AM >> for any new custom table AM. > > Yeah, I noticed this, too. +1 for doing something about it. Not sure > exactly what is the best approach.
One thing which is a bit tricky is that for example with COPY FROM we have a code path which is able to release a buffer held by the bulk insert state. So I think that we could get easily out by combining the bistate free path with finish_bulk_insert, create the bistate within the AM when doing a single or multi tuple insert, and having one extra callback to release a buffer held. Still this last bit does not completely feel right in terms of flexibility and readability. Note as well that we never actually use bistate when calling table_tuple_insert_speculative() on HEAD. I guess that the argument is here for consistency with the tuple_insert callback. Could we do something separately about that? -- Michael
signature.asc
Description: PGP signature
