> On 11 Nov 2019, at 09:32, Michael Paquier <michael@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
