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 1ohvo3-00050N-1H for pgsql-hackers@arkaria.postgresql.org; Mon, 10 Oct 2022 16:39:07 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1ohvo1-00041k-Rl for pgsql-hackers@arkaria.postgresql.org; Mon, 10 Oct 2022 16:39:05 +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 1ohvo1-00041b-Gc for pgsql-hackers@lists.postgresql.org; Mon, 10 Oct 2022 16:39:05 +0000 Received: from mail-pj1-x1031.google.com ([2607:f8b0:4864:20::1031]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1ohvnz-0006Ub-3w for pgsql-hackers@postgresql.org; Mon, 10 Oct 2022 16:39:04 +0000 Received: by mail-pj1-x1031.google.com with SMTP id d7-20020a17090a2a4700b0020d268b1f02so4136994pjg.1 for ; Mon, 10 Oct 2022 09:39:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=OSJJyL43CyyruLgOyeW4Nu2mNRdrc0zjBNNzLOxIxwk=; b=mnrneJgrHCsWRotKZrdg77KDwG3SQTAPjSxY7KhQAE54fEkBwPuMzWGWCMD9mdX5XD /EzHzn1GLncMBU3WL/qddW5EQj9RwDt4lYPElCvSLzHlCDHdQPKQdIIu0pThZGF2UC6z mPt3skjAvACfoRyug4+3iR0jQWnsPtTNdc+RHybBlaTxDrcEEAnNY0u8ItnWRzIEiTlb +sZ3DpbgdoJNw/1ZFw8Pvs3fGizfR8fUd7BCDWsT5yUQRsUgUabaBJ9tQXBeTIEoH7SX zbFkV7M+gyYSBXOQ2kJfXzNtTwesLZM260UO9SzGQcdc+NqeBewdvFlB6nAYS98c0Iz2 5iJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=OSJJyL43CyyruLgOyeW4Nu2mNRdrc0zjBNNzLOxIxwk=; b=wCO2eWU8OfjE5WffLBMvC8Yjk1Y7Hj/TWxLEDEW0ReHb9KEuo1Pec+XMAqZqwvqXXG 55PyheiWgjBnLqdjUuisGxo8+GXMWp22x3qI2y+PCa2KSOrKKkok07G3T5wXrkk7ygcm BnSKuVxBXFIGBBCLkt/f0coLUiafvi5oERVnqdfeV62hylfwYirZo+C/ZHNxAgfrZqHB w1rH2juEZ0nvu+gjsrFM4E0jwVEM95rheX5oAYpfn9L3pun4oETaZuc7keJCrzVI8odR h1v/orRSX/3CzXIPnmBS+lXUGYwHYtO1w1+SyeSOHi/lxs1XvGaTBQXCVU4otbomhqQ5 4YdA== X-Gm-Message-State: ACrzQf1rzz8dNwHPx+5dtBlsMrZ+5dBaZdqk+I+9X7NeJkj8fo79T+Dg cgSGAsjfmsSrc+ih8OU8mTdoG7nV3c8= X-Google-Smtp-Source: AMsMyM64ktnvw7/a70Sth1cw9q6fVURmwj58aCyUsORRn+S1ZrTiZUD3qTcIjIegkbfLxuCl5WdMTQ== X-Received: by 2002:a17:90a:50:b0:20a:b146:e75e with SMTP id 16-20020a17090a005000b0020ab146e75emr21551299pjb.216.1665419942178; Mon, 10 Oct 2022 09:39:02 -0700 (PDT) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id v29-20020aa799dd000000b0056258a3606csm7109317pfi.215.2022.10.10.09.39.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 10 Oct 2022 09:39:01 -0700 (PDT) Date: Mon, 10 Oct 2022 09:38:59 -0700 From: Nathan Bossart To: Bharath Rupireddy Cc: Michael Paquier , Soumyadeep Chakraborty , "Sanaba, Bilva" , "pgsql-hackers@postgresql.org" Subject: Re: Adding Support for Copy callback functionality on COPY TO api Message-ID: <20221010163859.GA993859@nathanxps13> References: <253C21D1-FCEB-41D9-A2AF-E6517015B7D7@amazon.com> <20200930074151.GR1996@paquier.xyz> <20220802234919.GA841243@nathanxps13> <20221007214824.GA814385@nathanxps13> <20221008173741.GB882834@nathanxps13> <20221008211404.GA893744@nathanxps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, Oct 10, 2022 at 12:41:40PM +0530, Bharath Rupireddy wrote: > IIUC, COPY TO callback helps move a table's data out of postgres > server. Just wondering, how is it different from existing solutions > like COPY TO ... PROGRAM/FILE, logical replication, pg_dump etc. that > can move a table's data out? I understandb that the COPY FROM callback > was needed for logical replication 7c4f52409. Mentioning a concrete > use-case helps here. This new callback allows the use of COPY TO's machinery in extensions. A couple of generic use-cases are listed upthread [0], and one concrete use-case is the aws_s3 extension [1]. > I'm not quite sure if we need a separate module to just tell how to > use this new callback. I strongly feel that it's not necessary. It > unnecessarily creates extra code (actual code is 25 LOC with v1 patch > but 150 LOC with v5 patch) and can cause maintenance burden. These > callback APIs are simple enough to understand for those who know > BeginCopyTo() or BeginCopyFrom() and especially for those who know how > to write extensions. These are not APIs that an end-user uses. The > best would be to document both COPY FROM and COPY TO callbacks, > perhaps with a pseudo code specifying just the essence [1], and their > possible usages somewhere here > https://www.postgresql.org/docs/devel/sql-copy.html. > > The order of below NOTICE messages isn't guaranteed and it can change > depending on platforms. Previously, we've had to suppress such > messages in the test output 6adc5376d. I really doubt that this small test case is going to cause anything approaching undue maintenance burden. I think it's important to ensure this functionality continues to work as expected long into the future. [0] https://postgr.es/m/253C21D1-FCEB-41D9-A2AF-E6517015B7D7%40amazon.com [1] https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/postgresql-s3-export.html#aws_s3.export_query_to_s3 -- Nathan Bossart Amazon Web Services: https://aws.amazon.com