Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qM5lw-001O5e-0P for pgsql-hackers@arkaria.postgresql.org; Wed, 19 Jul 2023 11:55:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1qM5lt-004Ut6-4Z for pgsql-hackers@arkaria.postgresql.org; Wed, 19 Jul 2023 11:55:09 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qM5ls-004Usx-PR for pgsql-hackers@lists.postgresql.org; Wed, 19 Jul 2023 11:55:08 +0000 Received: from mail-pj1-x102d.google.com ([2607:f8b0:4864:20::102d]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qM5lp-000J3q-RY for pgsql-hackers@lists.postgresql.org; Wed, 19 Jul 2023 11:55:07 +0000 Received: by mail-pj1-x102d.google.com with SMTP id 98e67ed59e1d1-2657d405ad5so4689673a91.1 for ; Wed, 19 Jul 2023 04:55:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=timescale.com; s=google; t=1689767704; x=1692359704; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=gdC2jjgtxlrnh7vdqw767espkZY5s+K+ZoHOuviZIi8=; b=ef0dYXskMXntymentgfnkgXUp3vjcWSPlVICCo0xctPMjluTBPh5ell3Usl3YZVgmj RqoTe72l/brMLu9DlQPhZuyn6EIBvnpewgunGmDAeocAJfbyfARNRbhklTMS/ZLkznLE aGOmo5jzVq6xW2ZMn+7Nb3gAsHBx9Sy0YgqH1DSQHBbyymF2pEcHYbqaqNmjU0ian4pf SSa9MdeWBTkQ9sGtVz1aD3PBB9vDVHvyTHBp9z8iP9e0i8t70sCzZO2F+wbsiAMpHGxX /dYaQUKHig/eZe0x65chN/SVP3ONgg7oFzgTpJNdDuE3V8T5ZQmVF+SRaEWogR4hi/12 E94Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689767704; x=1692359704; h=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=gdC2jjgtxlrnh7vdqw767espkZY5s+K+ZoHOuviZIi8=; b=iutNHvyGpwz/aSkf1vEYT3Ehg4YEH8ZKphHefh/2qn0LnK0wnAhKCbD34lqtYegHwR tEOm6iPsUhR1ISdSRY6vFUUuxpb/4aCsNz1vJq0tKMh9QoFZT37H/yXInZtlfrhb96Pt WzfCMso8T5j1n4RU5gY5G8giNgCHjfoUPEqDe+MUr9HWOtUnmKHMAOBhPh5bp/FjVCR+ CEBa4gUSDnn8Vtwvd3TLt1nAW5G3ZO5PU4FBsRdNKDjcrVeRypEjkjcR4VcLoQQX9gV+ A/YcR998cqISMvMyFIOr9pYuZhAvJpb8+d/0XL4mScWINgIu1Nd+dRpCfvIEJ3KxR4W9 HCPQ== X-Gm-Message-State: ABy/qLZiDrDxt8SE8DoSCmKzYCUaFJNTOzvwehrlVWC/rbSutN++c9xM CQGvfWIkMDzGAeqTrEOyi0jdIP2ZbKDIEWg72PA7MsIpBrTcaFl1FW1poA== X-Google-Smtp-Source: APBJJlH3m075WYlrg8PUTTMuw0flUh8R7HTZAJW9dxZwkyhu7vIvqygkfQmR93ws0jSW8VEUMNO4XUfWofQYCXvmQyA= X-Received: by 2002:a17:90b:1a90:b0:263:2da2:fe9b with SMTP id ng16-20020a17090b1a9000b002632da2fe9bmr1939227pjb.21.1689767704701; Wed, 19 Jul 2023 04:55:04 -0700 (PDT) MIME-Version: 1.0 References: <13971415-416b-1e98-2fe5-ad394c6ddc2c@timescale.com> <7eca2186-5da7-9e3c-6faf-ced69536031c@timescale.com> In-Reply-To: <7eca2186-5da7-9e3c-6faf-ced69536031c@timescale.com> From: Aleksander Alekseev Date: Wed, 19 Jul 2023 14:54:53 +0300 Message-ID: Subject: Re: RFC: logical publication via inheritance root? To: PostgreSQL Hackers Cc: Jacob Champion , Peter Smith , Amit Kapila Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, > v3 also fixes a nasty uninitialized stack variable, along with a bad > collation assumption I made. I decided to take a closer look at 0001. Since pg_get_relation_publishing_info() is exposed to the users I think it should be described in a bit more detail than: ``` + descr => 'get information on how a relation will be published via a list of publications', ``` This description in \df+ output doesn't seem to be particularly useful. Also the function should be documented. In order to accomplish all this it could make sense to reconsider the signature of the function and/or split it into several separate functions. The volatility is declared as STABLE. This is probably correct. At least at first glance I don't see any calls of VOLATILE functions and off the top of my head can't give an example when it will not behave as STABLE. This being said, a second opinion would be appreciated. process_relation_publications() misses a brief comment before the declaration. What are the arguments, what is the return value, are there any pre/postconditions (locks, memory), etc. Otherwise 0001 is in a decent shape, it passes make installcheck-world, etc. I would suggest focusing on delivering this part, assuming there will be no push-back to the refactorings and slight test improvements. If 0002 could be further decomposed into separate iterative improvements this could be helpful. -- Best regards, Aleksander Alekseev