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.96) (envelope-from ) id 1wJY2N-000Y6Q-3A for pgsql-hackers@arkaria.postgresql.org; Sun, 03 May 2026 14:43:16 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wJY1M-003gOb-09 for pgsql-hackers@arkaria.postgresql.org; Sun, 03 May 2026 14:42:12 +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.96) (envelope-from ) id 1wJY1L-003gOT-0O for pgsql-hackers@lists.postgresql.org; Sun, 03 May 2026 14:42:11 +0000 Received: from m16.mail.163.com ([220.197.31.4]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wJY19-00000000E4o-2xa8 for pgsql-hackers@postgresql.org; Sun, 03 May 2026 14:42:07 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; bh=5NQkLbTd7+FIKmq4BkizLUvgxnkQHxKZNxs3IB02tv4=; b=GKxHp2NNMBVlArDQJvzJAmvUR27WnCvVYEh6AbTeK7FoT2qPnODE4SY4C4DWeS 6nGZNFC5Ua+xTe2H1N1qBXCIpAW7KCuseyHvzzQkSz7rfDRcxx0+IsdJpUe4yXwQ tf9fIk/iBZ+0lwJSdax/yIOH8viYPCH1ZvwSEaNwbTO3M= Received: from andy-coding (unknown []) by gzsmtp2 (Coremail) with SMTP id PSgvCgBXfRaXXvdpJBueCw--.42755S3; Sun, 03 May 2026 22:41:28 +0800 (CST) From: Andy Fan To: David Rowley Cc: pgsql-hackers , Tom Lane Subject: Re: Make printtup a bit faster In-Reply-To: (David Rowley's message of "Fri, 30 Aug 2024 12:38:50 +1200") References: <87wmjzfz0h.fsf@163.com> <87bk1aj2go.fsf@163.com> Date: Sun, 03 May 2026 22:41:27 +0800 Message-ID: <877bpk7dyg.fsf@163.com> MIME-Version: 1.0 Content-Type: text/plain X-CM-TRANSID: PSgvCgBXfRaXXvdpJBueCw--.42755S3 X-Coremail-Antispam: 1Uf129KBjvdXoW7XF18Gr4kZr1DWFW3Kw4Uurg_yoWkJFXEka 92qFy8ur47CF17Aay3AF4jyF98tw4jkr1fXw4rZ390vryUZFs8uw4DCrZrZFn3Jr47Wrn7 CFs0yFy3K39FkjkaLaAFLSUrUUUUjb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUvcSsGvfC2KfnxnUUI43ZEXa7xR_ku47UUUUU== X-Originating-IP: [2409:8a1e:9912:9d30:b192:2460:a9a7:553d] X-CM-SenderInfo: x2klx3xlid0iqsrtqiywtou0bp/xtbC-xgWaWn3Xpi8vgAA3C List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi David, > On Fri, 30 Aug 2024 at 12:10, Andy Fan wrote: >> What would be the extra benefit we redesign all the out functions? > > If I've understood your proposal correctly, it sounds like you want to > invent a new "print" output function for each type to output the Datum > onto a StringInfo, if that's the case, what would be the point of > having both versions? You understood me correctly and I thought we should maintain one version two years ago, so I tried to implement this idea today. The first issue I want to talk about now how to define the function protocol in SQL, take int4out for example: master: cstring int4out(integer); New protocol: void int4out(integer, internal). and the internal is StringInfo acutally. The direct impaction would be: master support: postgres=# select int4out(8); int4out --------- 8 (1 row) After our change, user could not invoke any {type}out function anymore in SQL since it takes 'internal' as an agrument. I am not sure if people would write SQL like this, but it'd be good to have a talk about this. -- Best Regards Andy Fan