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 1vC44d-008YIE-0a for pgsql-hackers@arkaria.postgresql.org; Thu, 23 Oct 2025 22:46:22 +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 1vC44b-00CL7r-Vw for pgsql-hackers@arkaria.postgresql.org; Thu, 23 Oct 2025 22:46:21 +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 1vC44a-00CL7i-Tb for pgsql-hackers@lists.postgresql.org; Thu, 23 Oct 2025 22:46:20 +0000 Received: from sonic322-19.consmr.mail.gq1.yahoo.com ([98.137.70.82]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vC44W-003t1I-0E for pgsql-hackers@postgresql.org; Thu, 23 Oct 2025 22:46:19 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1761259570; bh=WSKalCbfH4HKYC4+I3Ks7uA1bTY/HpRiAV1ZBcjobNs=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To; b=ZbwImMzDzckeO4k8g+2kwUcL+d960RI1MLqwGQq88HPvbSjnCJrGPiJWufZ8CigA+lZYto8EYZHuRJ5k1JKrGt4kpCfmCcTdDHLVWyhfu5F2agxHegNk3SZlqwBL0Fk39cjobxuNQCQOeycgLOw6FaSszmareShGXNgaMFwN9QW0NbSqkrqL49y2niNUxUDPp9x6QiW9Vhej95jVTvADkkfaqoOKxjtamEWQDM0NDLm2ZEi+CS9urkaPWyWq0JLF8UkePmR6FZUlG452IWCmZszVv5MDmEVjpYddblxeg3oskIsQ6U6FF60WKwhyUBt7OnpGY3HWsz1gkYpDJBJCgA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1761259570; bh=JfUQXEUE3NfT5trEGQ2VCXzErDUYi6MGVRfmKz5rUWu=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=fErbe0jU6ZzZfL+Sjtb0f/5nux8vmPgAjViXQbxTmVw1eZ6/FcpgpARGFlu7+0bwrGpewYEfXDj1w9BR9XFVRcRgxBiq2+nEnfQpjJOGQfd6tvEIjjxw8DYqi9xm8hhtjJUl2NVxX3GDSbZ6sZ1PacRWCxw3tSuGcVo/q+xhvZsrh6RwvS2tWZ47hboSN0uL3XrriUvPOJ3UNufJy3gvgx6r+PvQZ0i6cUUn2NjVmVQ2xLjNG9K8QXlvzq4VS35qgqPGxG27qCBvJE5WO8WZqdlph2XDE5o4MTLUJVwnseQTjeucE125tEBhrtkuS7irOegvHcCxnIX5s5aQkf7DjQ== X-YMail-OSG: JBV1msYVM1nhRm79SUH_Aes81E9O83c93CyZMZav9wQlIKtt7Tf1ZUnL9N76ID6 OcdOFwe9hykdwpbjVYBf0ekTV0Sib3GpMVBKvU.r6WQiA4hbxR0Qzpsugn0fWZrqweR5gX8UCRxg ATVC0of5p9YTmpznCMQ8kBd0LPRL9xC__KygViKDtyTU__XpKQY2oI8zBmZ.LlzOecmqtJAeAZtx HwNx2S.HnP5HFztLJVaYC2WGL0M4NZer_efZi8b966DRZZxoBg77DlqlqBaPM4SKJCXXA9XgKK1W Uq0yYhjfZ1TWv7E2.u35W.8nbM9rjw.X6dPvOZv3cSiMTkV4we_tcG1QC_wSo8jbA6aYX.83o60W WzO69riTsgZUl2T6vCfvAGr.LwI9_vnT5XiXacZ4x2lqF_1wn5ajfB7hQP0GseuGLxj2lZvFq1fe B.Wif9efcYsX0wknv3QNrEOiXaxcruKm8PZaYLtv_jtXSFYDduZo3YGh.kvrzeTbB1nf4JPVXWBD vPS1Dsm5mDBafC69zbz0Ry5HZDG0aeR5Qto33FxSEuxREIjPU_HCje6yXAVHwb1diSKtts_Abmid AkL0.ig6WHRY9soLWN4_fJvXTCQXZCnG9OssxFxyDivStNUObVA0f88PSK2ELY_TtCJCrIBDCCFQ 0SAXNVVqLdZpRepElWd.o61ZBQMvcIf2uaexAzuV4XhcK5JZvXlNoHQZw8cVNxj0Oz7_3.fnF9Bb 5qLvQDFyn1Rn9XWGt1jzkVgOpb8V.36hRA0VNuMwWwGfXKw1fX9KH5a01LAZ8T0YjT8GYURkQJZs i2H7PW4lIsAkwY6iJYP26N.DhpxNWKndxFZcmL3FF_uFZFYJe55KrkI8uV4OlDpYQTih6VrUWxP0 4Y3pfKAlYzJnhRqePDsAuls.3d3gyyp0rzpnv3W1gRIzvO9m_PfqLBZXnjr4I7EYbj860TMwhrWv jISb9iqMhyOjdVv5mIo0H4NvtABFDrwzLkXRUYOX7Qf_Au6S9DhVp.LQP1pbhPn0Vkg_1.la9ote IX4ACPN3DktJ_RlE2oDcrdzPCM0fhLT.205Ua6gvRAMIIpHDkqIQGxqDo2dhP0he1NkqrHsUImna V6zFK0x5oDZJxX_kr7at5YlcOpu2SqaqH3AdoipOWFFMx4E1rJ1l5dMGN5k.d41iOqmxwfjBRyey WjRaMLLBV3oA0vTqFiGNnIAFWnaWTtoeGLuQ9fSYISPMZU2gLCUTWjj4r4dQ5KGLF1tjfTJnuUCA P1ripvOAPI5V5iQNB2CC_Pk77HlyMT15fVvWjL9KSPrEtEb5qxjfqPUVpqwQqI8580QdHi7zysRk Qt4sAmLNFj3bDR6OSc27w5ueBeSwu7Gw80ncXKkPMgcuizNtfIRZ6ZPHE6ge3RPqJkDFdyrj3ElP s0e6_0fgtj5coPJu5WMb7ojjOdklA9nzgFJZ.sClT4rO_QSbbiRbvvt1FrL03TGJ7R6SEkvFDAIG xyKJdvLocG1tW1MWsL7UQbRMsVhA_zY6gQ3ivhjv6cgFtJj5uEBBB0rHfn9jiAC_ZoiS3ufJtsL9 48rakqqd3GmSN3BuDgSERNL6884y.EVrjKk0jXvi2iF56CJANm9ah3IVzvPcew9jcEKX.CRY9OZh rrfW_Bi1cTvpQ5jK5I3tOhubp6lvXQiQ7r7wula.m0x1e1Pt2XDAImGG6L.PO4E_KqttXG_Pg5.h osnTX_sn5sQSNSLSTxKJ.ZDxUdlaazV8Mq.ue.Yxa.MBmg41xX45wo1.06U._uoy5hLtiSQXZUT8 DxbRqMh3qU5JOci80cWSNx7oVsNA3tosLpqA6qLG5BKwJj4qvzGf_VYQe1Y72nEHoXUpTVAE2s2S 41VBZHq..TquLtmD_5NFvyhgJbQIh5NUr9JN6NbLDPSqQOQpFBneFqaXftd84nJVqxPhQZpzaA38 8GmUtLcQqIdfYoJYEvX2ZI7s3ZBLPKfPGDJxZZYABITs9Bzd2tP8BYog7E_iJplwyJ7C.LLnGodx 40MfJahfeN1POuwvLOCzq8rpMARPNgZy64rfCnRtBtIRRVrnY.WAgSP8CvJxsen5lcrhLqGe76Jj U7kObvGey8pJtHzlmX7rY_NnGIE53ygeDPj8GlmKCW4IJltsgKfV98Dx_16AqUyf_fJe5_PofXWM G9WsjhF0V_LGpWm2LCtcNbCNqBg19fvtVwGDjoo850tXu8H335tYmA1YL0VmBETh3u7000cZ1wYG wSBH0mCrnU_onM5f9s.4KRNw694QJ7fnkp7AUVhx9pQVb4j9ZqxUjaoGIS_sjAAdfHS.8mqEVO6k 4GV1hT3tQRdTETQ-- X-Sonic-MF: X-Sonic-ID: 98798bc3-9437-41ea-a469-3fedc559416d Received: from sonic.gate.mail.ne1.yahoo.com by sonic322.consmr.mail.gq1.yahoo.com with HTTP; Thu, 23 Oct 2025 22:46:10 +0000 Date: Thu, 23 Oct 2025 22:45:48 +0000 (UTC) From: Sergey Prokhorenko To: Masahiko Sawada Cc: Andrey Borodin , pgsql-hackers Message-ID: <1846725727.103615.1761259548268@mail.yahoo.com> In-Reply-To: References: <1791665551.452444.1761209220211.ref@mail.yahoo.com> <1791665551.452444.1761209220211@mail.yahoo.com> <18022523-0F8F-4C07-AFF5-57DC9086D78E@yandex-team.ru> <1895971769.8343.1761240853939@mail.yahoo.com> Subject: Re: Add uuid_to_base32hex() and base32hex_to_uuid() built-in functions MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_103614_1876526855.1761259548267" X-Mailer: WebService/1.1.24652 YMailNorrin Content-Length: 8702 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk ------=_Part_103614_1876526855.1761259548267 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > Given that what uuid_to_base32hex() actually does is encoding theinput UU= ID,=C2=A0 I find that it could be confusing if we have a similar function other than encode() function. Also, we could end up introducing as many encoding and decoding functions dedicated for UUID as we want to support encoding methods, bloating the functions. > So as the first step, +1 for supporting base32hex for encode() and decode() functions and supporting the UUID <-> bytea conversion. I believe it would cover most use cases and the cost of UUID <-> bytea conversion is negligible. > Regards, > --=20 > Masahiko Sawada > Amazon Web Services:=C2=A0https://aws.amazon.com Masahiko, I see you're in favor of base32hex encoding. That's great! Your arguments make sense, and I generally support enhancing the standard e= ncode() and decode() functions to handle base32hex. It seems like the right= approach from a developer experience standpoint. However, I'm unclear about some implementation aspects. Why add=C2=A0conver= sions between UUID and bytea data types? Wouldn't that require creating ded= icated UUID <-> bytea conversion functions? Instead, could we implement enc= ode() as polymorphic to handle UUID type inputs directly? For decode(), we'= d need =C2=A0some way=C2=A0(a parameter?) to specify the=C2=A0UUID output t= ype instead of bytea. Another option would be automatic type casting when i= nserting bytea data into UUID columns. Neither an extra parameter nor addit= ional type casting seems ideal to me, though I don't have better alternativ= es. But actually, for a short UUID text encoding to succeed, it's more impo= rtant that it becomes the single, de facto standard.=C2=A0We should avoid s= upporting multiple encodings, just as the authors and contributors of RFC 9= 562 did:=C2=A0https://github.com/uuid6/new-uuid-encoding-techniques-ietf-dr= aft/discussions/17#discussioncomment-10614817=C2=A0=C2=A0 =C2=A0Therefore, = whenever possible, encode() and decode() should support just one UUID text = encoding, namely base32hex. Best regards,Sergey Prokhorenko =20 ------=_Part_103614_1876526855.1761259548267 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> = Given that what uuid_to_base32hex() actually does is encoding the
inp= ut UUID,  I find that it could be confusing if we have a similar
function other than encode() function. Also, we could end upintroducing as many encoding and decoding functions dedica= ted for UUID
as we want to support encoding methods, bloa= ting the functions.

> So as the fir= st step, +1 for supporting base32hex for encode() and
dec= ode() functions and supporting the UUID <-> bytea conversion. I
believe it would cover most use cases and the cost of UUID <= ;-> bytea
conversion is negligible.
=
> Regards,

> = --
> Masahiko Sawada
> Amazon We= b Services: https://aws.amazon.com

=

Masahiko,

I see you're in favor = of base32hex encoding. That's great!

Your arguments make sense, and I gene= rally support enhancing the standard encode() and decode() functions to han= dle base32hex. It seems like the right approach from a developer experience= standpoint.

However, = I'm unclear about some implementation aspects. Why add c= onversions between UUID and bytea data types? Wouldn't that require creatin= g dedicated UUID <-> bytea conversion functions? Instead, could we im= plement encode() as polymorphic to handle UUID type inputs directly? For de= code(), we'd need  some way (a parameter?) to specif= y the UUID output type instead of bytea. Another op= tion would be automatic type casting when inserting bytea data into UUID co= lumns. Neither an extra parameter nor additional type casting seems ideal t= o me, though I don't have better alternatives.
But actually, for a short UUID text encoding to = succeed, it's more important that it becomes the single, de facto standard.=  We should avoid supporting multiple encodings, just as th= e authors and contributors of RFC 9562 did: https://github.com/uuid6/new-uuid-encoding-techniques-ietf-draft/discuss= ions/17#discussioncomment-10614817    Therefore, wheneve= r possible, encode() and decode() should support just one UUID text encodin= g, namely base32hex.

Best = regards,
Sergey Prokhorenko




------=_Part_103614_1876526855.1761259548267--