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 1rzyYz-008W5Z-NV for pgsql-hackers@arkaria.postgresql.org; Thu, 25 Apr 2024 12:50:57 +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 1rzyYy-006Yqu-2j for pgsql-hackers@arkaria.postgresql.org; Thu, 25 Apr 2024 12:50:56 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rzyYx-006Yqm-P4 for pgsql-hackers@lists.postgresql.org; Thu, 25 Apr 2024 12:50:55 +0000 Received: from mail-ej1-x634.google.com ([2a00:1450:4864:20::634]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rzyYt-002ssW-1f for pgsql-hackers@lists.postgresql.org; Thu, 25 Apr 2024 12:50:54 +0000 Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-a52223e004dso108372466b.2 for ; Thu, 25 Apr 2024 05:50:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714049450; x=1714654250; darn=lists.postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=FOMVhZbIONzPlPZmMTW34rm6cIncv6LwX5TLRid4494=; b=P3KNX5NO3emfDGF5VrwDEt87cEn/q/YBwLEYjftofBRLG7CePVhP1lNDkhPcnr7jWu iaYVlU1u5KeglyjA1M5B+EXm0/2sODCIHXlQAUHkiZu+BgWO3MxEDGmTpj0te0Ev33jI d9OyQB95AiFc7Mwr1pG11gUp1CvUkkbKu+vLK5UQSkEG03GDyaDL9F03fFMjqNLV4v2z wFFwuV4BGYe1GV8G8j0771Nb6W+L+XDnUidnd+EVkLtkDhNtlIjd9A9LOhRLKuyEHAK/ j0lcFv8YnGumVrvukMitJbYTpD+x/OBazHNAdudpXC8i8bjFjd3A1YuHmPS9Xcn/vu8k wfgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714049450; x=1714654250; h=content-transfer-encoding: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=FOMVhZbIONzPlPZmMTW34rm6cIncv6LwX5TLRid4494=; b=TQIMRjlEbhLXgySlJX2Do4WRgpFuW2MqwA/ZfOIuJJtVZ5SGJJkf37dgkyp0wRkbhf hC6YZ0ysljdE/t/pRlEYwB/Jhar8Es++14yWJxgfSRnTGnQB5h/hZ0ETSB6b5gnKMT9R mplKD3GFcVx7ILfE4TMw14YCKoefmDFQs5z3cTw1tlLy8zYZ6Ll5zG3bLQ36zJ5QNTUx zg4A69D8+d+NKka4+jXmbND5aAtUV3LVn0wZgBwntBiPft6oJzCA3TMY0F62LtkqEjye 3MxvCCBRxLufMgA/PbJHbsjk6OV0j2AqfS5Qp7w0f/twjJmoXHkljvJJt1dW+XG9eptT MbGA== X-Forwarded-Encrypted: i=1; AJvYcCXcUqloh8sKcfMZBiIXax+y+rXbKl1DXwrPKdvBEemMHxQQHhxIKLcVmFR1C8YxGzRd9/1/f4Lp0rYCL8OpcEGdrDdsUtYOmI0EQ92SA6pWLsnl X-Gm-Message-State: AOJu0Yy7qwFCpMvc/5kUPCMF1WWuk5JFWUgBfBx4iRsLQIusjBLr3FEE y9Qmv4pFLRrS7O18AzpP9JW9Zg4oMWfR3p80LhIm96nQvOK77vCzCj93tq9d3j8Xieya2UQjWFN hNPaFZgi54zeRyUJjWLQkVLxW2Ts= X-Google-Smtp-Source: AGHT+IEmlQHp2j4uTE/rcySdUeBMkhP85qskauHbh40GGpiqC192LeJ5R6qjzrmK1z5ADXLrXJbUHsHZJrrMvgYJezY= X-Received: by 2002:a17:906:a08e:b0:a58:7c50:84e4 with SMTP id q14-20020a170906a08e00b00a587c5084e4mr4950132ejy.2.1714049449868; Thu, 25 Apr 2024 05:50:49 -0700 (PDT) MIME-Version: 1.0 References: <3833077.1714020280@sss.pgh.pa.us> In-Reply-To: <3833077.1714020280@sss.pgh.pa.us> From: Robert Haas Date: Thu, 25 Apr 2024 08:50:38 -0400 Message-ID: Subject: Re: Why don't we support external input/output functions for the composite types To: Tom Lane Cc: Dilip Kumar , PostgreSQL Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This thread caught my eye this morning, and I'm confused. On Thu, Apr 25, 2024 at 12:44=E2=80=AFAM Tom Lane wrote= : > The primary outcome would be to require a huge amount of new work > to be done by a lot of software, much of it not under our control. What, what is the "lot of software" that would have to be changed? It can't be existing extensions, because they wouldn't be forced into using this feature. Are you thinking that drivers or admin tools would need to support it? To me it seems like the only required changes would be to things that know how to parse the output of record_out(), and there is probably some of that, but the language you're using here is so emphatic as to make me suspect that you anticipate some larger impact. > And the impact wouldn't only be to software that would prefer not > to know about this. For example, how likely do you think it is > that these hypothetical user-defined I/O functions would cope > well with ALTER TABLE/ALTER TYPE commands that change those > rowtypes? Hmm. Dilip mentioned changing the storage format, but if you do that, you have bigger problems, like my_record_type.x no longer working. At that point I don't see why what you have is properly called a record type at all. So I guess what you're imagining here is that ALTER TABLE .. ALTER TYPE would try COERCION_PATH_COERCEVIAIO, but, uh so what? We could probably fix it so that such coercions were handled in some other way, but even if we didn't, it just means the user has to provide a USING clause, which is no different than what happens in any other case where coerce-via-I/O doesn't work out. --=20 Robert Haas EDB: http://www.enterprisedb.com