> On 11 Nov 2019, at 09:32, Michael Paquier <mich...@paquier.xyz> wrote:
> This part has resulted in 75c1921, and we could just change > DecodeMultiInsert() so as if there is no tuple data then we'd just > leave. However, I don't feel completely comfortable with that either > as it would be nice to still check that for normal relations we > *always* have a FPW available. XLH_INSERT_CONTAINS_NEW_TUPLE will only be set in case of catalog relations IIUC (that is, non logically decoded relations), so it seems to me that we can have a fastpath out of DecodeMultiInsert() which inspects that flag without problems. Is this proposal along the lines of what you were thinking? The patch is now generating an error in the regression tests as well, on your recently added CREATE INDEX test from 68ac9cf2499236996f3d4bf31f7f16d5bd3c77af. By using the ObjectAddresses API the dependencies are deduped before recorded, removing the duplicate entry from that test output. AFAICT there is nothing benefiting us from having duplicate dependencies, so this seems an improvement (albeit tiny and not very important), or am I missing something? Is there a use for duplicate dependencies? Attached version contains the above two fixes, as well as a multi_insert for dependencies in CREATE EXTENSION which I had missed to git add in previous versions. cheers ./daniel
catalog_multi_insert-v5.patch
Description: Binary data
