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 1t95Vw-007hPM-Fv for pgsql-general@arkaria.postgresql.org; Thu, 07 Nov 2024 16:37:43 +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 1t95Vt-00HK8i-4o for pgsql-general@arkaria.postgresql.org; Thu, 07 Nov 2024 16:37:41 +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 1t95Vs-00HK8Z-4T for pgsql-general@lists.postgresql.org; Thu, 07 Nov 2024 16:37:41 +0000 Received: from fout-b5-smtp.messagingengine.com ([202.12.124.148]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t95Vp-000f3e-AX for pgsql-general@postgresql.org; Thu, 07 Nov 2024 16:37:39 +0000 Received: from phl-compute-05.internal (phl-compute-05.phl.internal [10.202.2.45]) by mailfout.stl.internal (Postfix) with ESMTP id AC30711400EF; Thu, 7 Nov 2024 11:37:36 -0500 (EST) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-05.internal (MEProxy); Thu, 07 Nov 2024 11:37:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aklaver.com; h= cc:content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1730997456; x=1731083856; bh=2KaMZhOKxHZJbD9+j2+3wGDtMwqxkRm7LlTHj4TsReo=; b= gtlA8Z2VhlcTjVIMaDe4SaBFQyG6N6ExiK9Bj5AsKOLpnXck6qu1Txbr1f7AkJ0d tLi7dA6bunLSIwXzB4DE1Hmy3uXG1iu6Cqf9sDeXvDyONBFB70s1HajZRV+9Nsn1 zgDJf9znOIYMUg5Z0IBhr4lopyH2JXtqAYoIya5JxIuFs3uuMgG5gChH037cDvdx NoMXafhiz5Bw8FW7BlXCg7EKn3+0HsVnAGIssk7RrLAevEIK/ABqfgK6oD25WEDR lDwD5h0mzogE0SvCcE16sPX51SrrqfucV7Wk6R3ZyuEO5ttyQxOA/H9aY2ICcfSA z0uAjTHF5ig9Ejbf8kWHgQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; t=1730997456; x=1731083856; bh=2 KaMZhOKxHZJbD9+j2+3wGDtMwqxkRm7LlTHj4TsReo=; b=Zk18vE3St38WILCW8 rwrY0TC8uuMnS0wYPoXLsldJSeRcs19mJJHXcYOLLPMdU29QZpLiA1pWHM+iHgX7 S647RwRyv6STlkAeKRjdGaO8/8eMo8ZkBLQEOm10lR5o8GimOsVO0XzW622LbugU 5yTcQRT1njeEXZ12y3oBVJxdym+I1YBhuHf8hFgCFjdEHRa+2rJLdwwgdVvp4/V/ RUPh+XSXkZMlehe95SoO8KKrP0Lq1vGA6t5rzdsD42fXIfcmhG2t5CyzJHAMiCCF hm2bmzSDP8gimuXqExF5LIP99BZ89oer44Y6z2enzjXwHf5IQgnm+UNKFo/x2k8A DNQEw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrtdeggdeltdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdpuffr tefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnth hsucdlqddutddtmdenucfjughrpefkffggfgfuvfhfhfgjtgfgsehtjeertddtvdejnecu hfhrohhmpeetughrihgrnhcumfhlrghvvghruceorggurhhirghnrdhklhgrvhgvrhesrg hklhgrvhgvrhdrtghomheqnecuggftrfgrthhtvghrnhepkeefheduvdejiefgieefjedt udduffelvdefleehfedtieffuefgvdekleegtddvnecuffhomhgrihhnpehpohhsthhgrh gvshhqlhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhl fhhrohhmpegrughrihgrnhdrkhhlrghvvghrsegrkhhlrghvvghrrdgtohhmpdhnsggprh gtphhtthhopedvpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopeguuggvvhhivghn nhgvsehgmhgrihhlrdgtohhmpdhrtghpthhtohepphhgshhqlhdqghgvnhgvrhgrlhesph hoshhtghhrvghsqhhlrdhorhhg X-ME-Proxy: Feedback-ID: i76984098:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 7 Nov 2024 11:37:35 -0500 (EST) Message-ID: <32fa25b0-7e5e-40d2-b3a8-e1cd1dbd833d@aklaver.com> Date: Thu, 7 Nov 2024 08:37:35 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: About the stability of COPY BINARY data To: Dominique Devienne , pgsql-general@postgresql.org References: Content-Language: en-US From: Adrian Klaver In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 11/6/24 08:20, Dominique Devienne wrote: >>>From https://www.postgresql.org/docs/current/sql-copy.html: > |> binary-format file is less portable across machine architectures > and PostgreSQL versions > > In my experience, the binary encoding of binding/resultset/copy is > endian neutral (network byte order), so what is the less portable > across machine architectures that warning about? > > Also, does the code for per-type _send() and _recv() functions really change > across versions of PostgreSQL? How common are instances of such > changes across versions? Any examples of such backward-incompatible > changes, in the past? > > The binary data contains OIDs, but if sticking to built-in types, > which OIDs are unlikely to change across versions? > > I'm obviously storing COPY BINARY data (we have lots of bytea > columns), and I wonder how bad it is long term, and across PostgreSQL > versions. If I where to hazard a guess this plays a part: https://www.postgresql.org/docs/current/sql-copy.html "To determine the appropriate binary format for the actual tuple data you should consult the PostgreSQL source, in particular the *send and *recv functions for each column's data type (typically these functions are found in the src/backend/utils/adt/ directory of the source distribution)." > > Thanks for any insights, --DD > > -- Adrian Klaver adrian.klaver@aklaver.com