Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1q93wE-0007ZE-J2 for pgsql-hackers@arkaria.postgresql.org; Tue, 13 Jun 2023 13:19:58 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1q93wD-000444-7Z for pgsql-hackers@arkaria.postgresql.org; Tue, 13 Jun 2023 13:19:57 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1q93wC-00043v-TO for pgsql-hackers@lists.postgresql.org; Tue, 13 Jun 2023 13:19:56 +0000 Received: from mail-oa1-x2c.google.com ([2001:4860:4864:20::2c]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1q93wA-001ymT-Hc for pgsql-hackers@lists.postgresql.org; Tue, 13 Jun 2023 13:19:55 +0000 Received: by mail-oa1-x2c.google.com with SMTP id 586e51a60fabf-1a694ac3238so1622195fac.3 for ; Tue, 13 Jun 2023 06:19:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686662393; x=1689254393; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=BVbJyURX7IzUd4Hf9hR7ZZgNrOwGLrZb3cC9tUsLRlc=; b=EKlEd/SgWBu43/bgNqIsOyNBywszpkDpCdtgzG1illQKKRX8caz6RXWXG0muMJEMJp icA86wrmdd71EIKtRmlBXmptu+aNWTN6DTx1teEMfabgcieZGx76xdKoBMHAvvTmddjs LABoVGrawlJzS5WOTZYUOYKgBrOXHtXLomDcHzjpWopEx+nrDrSz8csza1jrjffxeULN XvfHNaTUA3AYk56fxFzcugb7S4QApyOGU2TaVrip5kpsO3qdrEf+OpGzVR9wUGCRPOb0 ihwfOSz+lc8rBXPwTurVq6H4e2wsdQfpfMCY3QNFQk3ay21sB6ggGl4VpoHzB4Ztr0cw oqtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686662393; x=1689254393; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=BVbJyURX7IzUd4Hf9hR7ZZgNrOwGLrZb3cC9tUsLRlc=; b=C0L4R5BNM7D1y2C2tGjsIkU9X+4ND6FdsmRTaxzy60kJH59cka0/8mAnv1ebcUNfOu gkGnB+5jKtVdMe22WC3U9+63q25oak59vUyL/OcjOp31/k3+ewRMxpmgI9JkQL/EBY0e buZgb/DCe+2jKyZS3HY4wZjS/xCB/zMIhl+iVDHVM0T6TmKmvsPu8yYfRDgeclSBw3XL mgCQ8JHfWWQcfISCIhTiFp1LSxvJ/YWWdHQPKvrL8L1NOMT+RlALNzPoSpyOr36ZkYfA BPpNxFlUbQHiGc7Y7us2dEZd8lHaV1qAG8h8q8LmQewL0ppxSB6ZJEsieWeOYmJaknNE sCUg== X-Gm-Message-State: AC+VfDxlRObDi/+LGgSLEN8t1d19XT6pDSVX6pupPmHbFlFus96+SUUh mKfYlyq95YT/koqKE2+AXs3WVF5t894T/0Tea5E= X-Google-Smtp-Source: ACHHUZ4143fIKeC31opBNc3hdesA0eM82CKQZYVf644MyAI7y76IUOCFfcjIilme2aSs2eWB1h4lgk8lKNIrrsMXST4= X-Received: by 2002:a05:6870:6296:b0:192:79ba:ef35 with SMTP id s22-20020a056870629600b0019279baef35mr7180705oan.18.1686662393335; Tue, 13 Jun 2023 06:19:53 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Amit Kapila Date: Tue, 13 Jun 2023 18:49:42 +0530 Message-ID: Subject: Re: Support logical replication of DDLs To: Michael Paquier Cc: "Wei Wang (Fujitsu)" , shveta malik , "Yu Shi (Fujitsu)" , vignesh C , "Zhijie Hou (Fujitsu)" , Ajin Cherian , Runqi Tian , Peter Smith , Tom Lane , li jie , Dilip Kumar , Alvaro Herrera , Masahiko Sawada , Japin Li , rajesh singarapu , PostgreSQL Hackers , Zheng Li Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Jun 13, 2023 at 1:21=E2=80=AFPM Michael Paquier wrote: > > On Mon, Jun 12, 2023 at 01:47:02AM +0000, Wei Wang (Fujitsu) wrote: > > # load test cases from the regression tests > > -my @regress_tests =3D split /\s+/, $ENV{REGRESS}; > > +#my @regress_tests =3D split /\s+/, $ENV{REGRESS}; > > +my @regress_tests =3D ("create_type", "create_schema", "create_rule", = "create_index"); > > ``` > > I think @regress_tests should include all SQL files, instead of just fo= ur. BTW, > > the old way (using `split /\s+/, $ENV{REGRESS}`) doesn't work in meson. > > I have been studying what is happening on this thread, and got a look > at the full patch set posted on 2023-06-08. > > First, the structure of the patch set does not really help much in > understanding what would be the final structure aimed for. I mean, I > understand that the goal is to transform the DDL Nodes at a given > point in time, fetched from the event query code paths, into a > structure on top of which we want to be apply to apply easily > filtering rules because there could be schema changes or even more.. > But, take patch 0001. It introduces ObjTree to handle the > transformation state from the DDL nodes, and gets replaced by jsonb > later on in 0008. This needs to be reworked and presented in a shape > that's suited for review, split into more parts so as this is > manageable. > We have to choose one of the approaches between 0001 and 0008. I feel we don't need an intermediate ObjTree representation as that adds overhead and an additional layer which is not required. As mentioned in my previous email I think as a first step we should merge 0001 and 0008 and avoid having an additional ObjTree layer unless you or others feel we need it. I think that will reduce the overall patch size and help us to focus on one of the approaches. Surely, as suggested by you, we should also evaluate if we can generate this code for the various command types. --=20 With Regards, Amit Kapila.