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 1uMUR8-00DGqQ-Px for pgsql-general@arkaria.postgresql.org; Tue, 03 Jun 2025 16:24:27 +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 1uMUQ8-001t21-22 for pgsql-general@arkaria.postgresql.org; Tue, 03 Jun 2025 16:23:24 +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 <01020197369aac89-01a7b7b4-b775-471e-ac8e-de8b28d87008-000000@mail.rodonnell.ie>) id 1uMUQ7-001t1s-NF for pgsql-general@lists.postgresql.org; Tue, 03 Jun 2025 16:23:24 +0000 Received: from a7-22.smtp-out.eu-west-1.amazonses.com ([54.240.7.22]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from <01020197369aac89-01a7b7b4-b775-471e-ac8e-de8b28d87008-000000@mail.rodonnell.ie>) id 1uMUQ2-0001wP-0W for pgsql-general@postgresql.org; Tue, 03 Jun 2025 16:23:23 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=dv7fx26oobputowqxkzhnujragfvk7eg; d=rodonnell.ie; t=1748967796; h=Message-ID:Date:MIME-Version:To:From:Subject:Content-Type:Content-Transfer-Encoding; bh=jGuFzDbuK1KG8xQ+xxNumuDLy2y2GSz/EaQ0cHYpifE=; b=Cu66bcvfS4gP1PkTDclKFcYBkTH827SDAnyHaA7G9V48z00hbRTHbTSA6bj0FcSp Y6qZm3zlQlrbDX0sMwdCTqFpTNrpAqPmn0rocLRkstQ4lG5GmReYtGmL6vyrODm29xx cDMTykgkbDv5tLekvM3jox0lVmmFjjoY6ItDHjNf0b4L7b9oJBu7oSJzUiREJ3xXF7A rN+mjoYu1z+/h2yWPDRQLORj9RcjffYkSUmR1vKWL0E5m0otSPMFbFN5eJaSKZAggNP qWBrQBgxRxzmL6piLcv6Gmim0pjPy1l2iis5fplfDZUFTxrMHRI5FE0BK6lyMSc5dG3 35ffIbkC3Q== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ihchhvubuqgjsxyuhssfvqohv7z3u4hn; d=amazonses.com; t=1748967796; h=Message-ID:Date:MIME-Version:To:From:Subject:Content-Type:Content-Transfer-Encoding:Feedback-ID; bh=jGuFzDbuK1KG8xQ+xxNumuDLy2y2GSz/EaQ0cHYpifE=; b=h2JZG99mxS/qv/JHBg2jwTjpjA9mRzw0tBcHe0RAmMWGrdSmoy0WtLSlIfeECYPM JJSRqN6oeF9UtDD05fghcVCJi3z35txzySVbCXIoxv1yKc95qTzHOTCusV4fd8gbN0/ DFacLbI4cOTEelfUhGlUic2h8IOraJ6wQXybeL/I= Message-ID: <01020197369aac89-01a7b7b4-b775-471e-ac8e-de8b28d87008-000000@eu-west-1.amazonses.com> Date: Tue, 3 Jun 2025 16:23:15 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-GB, de-DE To: 'PostgreSQL' From: Ray O'Donnell Subject: Combining scalar and row types in RETURNING Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Feedback-ID: ::1.eu-west-1.Bw1eu/7Uepg3xcsiFBL71JJRCh2A2yTFrgBhhiulXmU=:AmazonSES X-SES-Outgoing: 2025.06.03-54.240.7.22 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Can you combine scalar and row types in a RETURNING clause? My use-case is getting the results of a MERGE - I'd like to be able to capture both the action performed and the modified row, something like this (this is in a plpgsql function): declare     m_action text;     m_new_data record; begin     merge into my_table t     using (         ....     ) s     on (t.id = s.id)     when matched then         update .....     when not matched then         insert .....     returning         merge_action(), t.*     into        m_action, m_new_data; end; In my case, m_new_data is actually a table row type rather than plain "record". The row is passed on to another function which calculates the altered columns and logs the changes. I've tried it, and it doesn't seem to work; I get an error, "m_new_data is not a scalar variable", so I'm guessing it's not possible, but it's worth asking... I know I can list the returned columns individually in the RETURNING and then use a row constructor to construct the row.... but it'd be handier if I could just derive the row directly from the MERGE query. Thanks in advance, Ray. -- Raymond O'Donnell // Galway // Ireland ray@rodonnell.ie