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 1njAQZ-0001Kp-EQ for pgsql-hackers@arkaria.postgresql.org; Tue, 26 Apr 2022 01:55:43 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1njAQY-00075R-7a for pgsql-hackers@arkaria.postgresql.org; Tue, 26 Apr 2022 01:55:42 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1njAQX-00074H-Ud for pgsql-hackers@lists.postgresql.org; Tue, 26 Apr 2022 01:55:41 +0000 Received: from mail-qv1-xf30.google.com ([2607:f8b0:4864:20::f30]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1njAQU-0006eC-Vs for pgsql-hackers@lists.postgresql.org; Tue, 26 Apr 2022 01:55:40 +0000 Received: by mail-qv1-xf30.google.com with SMTP id 1so2224609qvs.8 for ; Mon, 25 Apr 2022 18:55:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6c4A6Xq3bfy6AMqCIgU69WQ1rudGsHHo5OfQIGkX1O4=; b=IOQMaEjQf8cafHdHOi5gR32FJrtAEarRuP6boiuliXs+WhvQ7YpHE/T0mAmhAY3uLF i+PmAfIiGMwpJ7rMKzhQ5+HtUJrII3Y1UAm/0CqCbpR/V0kcA3PHUke/WZF+/y5V+fw/ YKC3sfi3i2r7atTLECn5ZGAM1UKky4p2oWGwTnVQFMXWIC4Ek6ZNjRrvXNDsZshG/+M+ fAaUJ5uiIXLQWJmz5OWoDc+2mASGeI5OyvdzbsrGuc80dFGS2LtmaNEXQ2ESawx3WLUx IpWySQMDAyOmzvGPUKtLnGhcazKSOIZB0eU6YqwnLrFlJIHjhnBjjIqhmWwEyt14nROc U42g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6c4A6Xq3bfy6AMqCIgU69WQ1rudGsHHo5OfQIGkX1O4=; b=h0zYze9i+6CbX5GQkSCfxbYeOiWuo8mdM96ymomQe0WAw3hsbhOfVmqtC+jSBaCf1H 8onTFJ7XIAfJ0kW0hH9TWLYJwtS4fENuHmaQ+ZH4oGY/WTHi8CDj2iDyBCwsDltcbhCF z6v66lv0onCI43FKERU18DF6kNwqzXhB0mP7xE8BqL18XGWrFI/PG/QC5ncRXuIOCR98 0VGlOOV+gbf6pFL2MfATaayHpX6fswd5u4F2xy2L4paCQjoZG9zFEwP0U4CVavRANtyr yU9XapMgBFIyo5SLyLIARbUdSIxqwhKdh3IlltTVVQouJRbFRvUFobeW8DyRnKQfce5v olVA== X-Gm-Message-State: AOAM531a0qhJJzq7JLDhzamTZ4ebP4MIpLFEfbAqnPH/9oUwoCmcItar fnpe912UGDsk0P8bpHGXlyKy7f6mNjvAtj4/eYU= X-Google-Smtp-Source: ABdhPJxmYQLggPwls4esJ5b61vflPCgyvZrNClip+W8Qzyj783YmZ6l2e81tvdrr60sTy6Tsa5ddciL+ib2m6vnjw0w= X-Received: by 2002:ad4:5bee:0:b0:444:474e:22d9 with SMTP id k14-20020ad45bee000000b00444474e22d9mr14959929qvc.117.1650938137379; Mon, 25 Apr 2022 18:55:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Peter Smith Date: Tue, 26 Apr 2022 11:55:21 +1000 Message-ID: Subject: Re: Skipping schema changes in publication To: Bharath Rupireddy Cc: vignesh C , PostgreSQL Hackers Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Sat, Apr 23, 2022 at 2:09 AM Bharath Rupireddy wrote: > > On Tue, Mar 22, 2022 at 12:39 PM vignesh C wrote: > > > > Hi, > > > > This feature adds an option to skip changes of all tables in specified > > schema while creating publication. > > This feature is helpful for use cases where the user wants to > > subscribe to all the changes except for the changes present in a few > > schemas. > > Ex: > > CREATE PUBLICATION pub1 FOR ALL TABLES SKIP ALL TABLES IN SCHEMA s1,s2; > > OR > > ALTER PUBLICATION pub1 ADD SKIP ALL TABLES IN SCHEMA s1,s2; > > > > A new column pnskip is added to table "pg_publication_namespace", to > > maintain the schemas that the user wants to skip publishing through > > the publication. Modified the output plugin (pgoutput) to skip > > publishing the changes if the relation is part of skip schema > > publication. > > As a continuation to this, I will work on implementing skipping tables > > from all tables in schema and skipping tables from all tables > > publication. > > > > Attached patch has the implementation for this. > > This feature is for the pg16 version. > > Thoughts? > > The feature seems to be useful especially when there are lots of > schemas in a database. However, I don't quite like the syntax. Do we > have 'SKIP' identifier in any of the SQL statements in SQL standard? > Can we think of adding skip_schema_list as an option, something like > below? > > CREATE PUBLICATION foo FOR ALL TABLES (skip_schema_list = 's1, s2'); > ALTER PUBLICATION foo SET (skip_schema_list = 's1, s2'); - to set > ALTER PUBLICATION foo SET (skip_schema_list = ''); - to reset > I had been wondering for some time if there was any way to introduce a more flexible pattern matching into PUBLICATION but without bloating the syntax. Maybe your idea to use an option for the "skip" gives a way to do it... For example, if we could use regex (for . patterns) for the option value then.... ~~ e.g.1. Exclude certain tables: // do NOT publish any tables of schemas s1,s2 CREATE PUBLICATION foo FOR ALL TABLES (exclude_match = '(s1\..*)|(s2\..*)'); // do NOT publish my secret tables (those called "mysecretXXX") CREATE PUBLICATION foo FOR ALL TABLES (exclude_match = '(.*\.mysecret.*)'); ~~ e.g.2. Only allow certain tables. // ONLY publish my tables (those called "mytableXXX") CREATE PUBLICATION foo FOR ALL TABLES (subset_match = '(.*\.mytable.*)'); // So following is equivalent to FOR ALL TABLES IN SCHEMA s1 CREATE PUBLICATION foo FOR ALL TABLES (subset_match = '(s1\..*)'); ------ Kind Regards, Peter Smith. Fujitsu Australia