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 1oadoZ-00010H-Up for pgsql-hackers@arkaria.postgresql.org; Tue, 20 Sep 2022 14:01:32 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oadoY-0005b8-KT for pgsql-hackers@arkaria.postgresql.org; Tue, 20 Sep 2022 14:01:30 +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 1oadoX-0005az-Je for pgsql-hackers@lists.postgresql.org; Tue, 20 Sep 2022 14:01:30 +0000 Received: from out3-smtp.messagingengine.com ([66.111.4.27]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oadoU-0007hZ-Lk for pgsql-hackers@postgresql.org; Tue, 20 Sep 2022 14:01:28 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id C7E575C009C; Tue, 20 Sep 2022 10:01:24 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Tue, 20 Sep 2022 10:01:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:reply-to:sender :subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; t=1663682484; x=1663768884; bh=Q 7gBD180Fw1LbdP81oJfZW9v25y+R0GwPlvnC1Fwc2E=; b=x5wJ16aicFV5AO9IE vF+iwU7s1BKXkMaYaL9KZzZu+KclqPYstCYuU+M2zpjHE0lt9vwFHRZ6bhN0f7i2 dFtZ5sIGeCpNJ4O4Th9ksP7cQAstohXi5dGFOXwrw3eNT+W2w2MQVziG7i3MyW14 mBtvUHKAn7/cu4SMGbrXJhDNPqSyIirx5kblCtOcxHsJFqfDopbprDVG8YmfLzvb gudH1CSXg3Pzg64oCMBSc1/FVHenmrf5OCPLnFAh96KC7bqQf4ffAaeR1PM2m/eo 1JiEHIiyG2eWe7sQ9z45QZc3Ialw/iTLBXlajpeXUgR2w1eo8e5Z8znj/vRB56U0 ebpug== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfedvledgjedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvvefukfggtggugfgjsehtke ertddttdejnecuhfhrohhmpeetlhhvrghrohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhr vgesrghlvhhhrdhnohdqihhprdhorhhgqeenucggtffrrghtthgvrhhnpedvkedtffduff dtffffheffhfejjefhgfeiueeukeejkeffgfdufffhudffffeuveenucffohhmrghinhep vghnthgvrhhprhhishgvuggsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrg hrrghmpehmrghilhhfrhhomheprghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhr gh X-ME-Proxy: Feedback-ID: ia2694551:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 20 Sep 2022 10:01:23 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id E85D038F; Tue, 20 Sep 2022 16:01:19 +0200 (CEST) Date: Tue, 20 Sep 2022 16:01:19 +0200 From: Alvaro Herrera To: Kyotaro Horiguchi Cc: houzj.fnst@fujitsu.com, mark.dilger@enterprisedb.com, amit.kapila16@gmail.com, tgl@sss.pgh.pa.us, peter.eisentraut@enterprisedb.com, pgsql-hackers@postgresql.org, robertmhaas@gmail.com Subject: Re: why can't a table be part of the same publication as its schema Message-ID: <20220920140119.mct473wrvvrikrg2@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20220913.134023.460492970872809991.horikyota.ntt@gmail.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2022-Sep-13, Kyotaro Horiguchi wrote: > At Mon, 12 Sep 2022 04:26:48 +0000, "houzj.fnst@fujitsu.com" wrote in > > I feel we'd better compare the syntax with the existing publication command: > > FOR ALL TABLES. If you create a publication FOR ALL TABLES, it means publishing > > all the tables in the database *including* tables created in the future. I > > think both the syntax and meaning of ALL TABLES IN SCHEMA are consistent with > > the existing FOR ALL TABLES. > > IMHO, I feel closer to Robert. "ALL TABLES IN SCHEMA" sounds like the > concrete tables at the time of invocation. While I agree that it is > not directly comparable to GRANT, What if we remove the ALL keyword from there? That would leave us with "FOR TABLES IN SCHEMA", which seems to better convey that it doesn't restrict to current tables in there. > but if I see "ALTER PUBLICATION p1 ADD SCHEMA s1", I automatically > translate that into "all tables in the schema s1 at the time of using > this publication". ... but that translation is wrong if replication supports other kinds of objects, as it inevitably will in the near future. Clearly the fact that we spell out TABLES there is important. When we add support for sequences, we could have combinations ADD [ALL] TABLES IN SCHEMA s ADD [ALL] SEQUENCES IN SCHEMA s ADD [ALL] TABLES AND SEQUENCES IN SCHEMA s and at that point, the unadorned ADD SCHEMA one will become ambiguous. > At least, it would cause less confusion when it were "ALT PUB p1 DROP > SCEMA s1" aginst "DROP ALL TABLES IN SCHEMA s1". I'm not sure what you mean here. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ "En las profundidades de nuestro inconsciente hay una obsesiva necesidad de un universo lógico y coherente. Pero el universo real se halla siempre un paso más allá de la lógica" (Irulan)