Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iR3Jo-0000Kp-5e for pgsql-hackers@arkaria.postgresql.org; Sun, 03 Nov 2019 00:00:33 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iR3Jm-0001al-MS for pgsql-hackers@arkaria.postgresql.org; Sun, 03 Nov 2019 00:00:30 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iR3Jk-0001aW-C0 for pgsql-hackers@lists.postgresql.org; Sun, 03 Nov 2019 00:00:30 +0000 Received: from out2-smtp.messagingengine.com ([66.111.4.26]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1iR3Jc-0006VW-Sg for pgsql-hackers@postgresql.org; Sun, 03 Nov 2019 00:00:27 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 7535C20D12; Sat, 2 Nov 2019 20:00:19 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Sat, 02 Nov 2019 20:00:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anarazel.de; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm2; bh=Df6WbrFdBBMTaOJdN9Qod8uqKJI SJXbMKtiDh+r2woU=; b=Lol8oLh5ytNFOK5/wxPfzFoSiKyAT60eRtXo5JllV4T PhxoMIz8ELTSc8aL4Gt0HzOqhpmSgEMYcnIS1CK4FRGABSGGb+t1HLZ8IpmtVWIu OaUAz1jPA/mH9sv1PyKjw6dpp4jelBSCZMDwXc5MQZL586uxBcmC4EAxUIJG6lbw KpSogtJkupZmzSe4bZdZ6BLvJHOJWwqu1WiMHNWPpnZy1SUYNx4cRrM1N0RqfDaN 6JfII0I1WBZ+GKoIzD5qnn5Ul+dy+Cdes14JWANIj5AexdcLfBh/a/9qlEe8pucO n8ONssxNT9wXdHcFQdA5NNQWkPgWuKCvJRruZSQxs3A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=Df6Wbr FdBBMTaOJdN9Qod8uqKJISJXbMKtiDh+r2woU=; b=rVrBlYur6fQnQ4QEn5IWIm JpRlMR6mnvMexRAzk4+Xo3oan3IcEjx9R8KBhrYWool/6QTh0ivzEBVtWDOLVddU 3h61Qixfu49mxmQCenLUMz5Uh9KlePNc7PSJe5S7sEY+2ohk6gAVv4kzUbK/eIuz GH0SWR2F8tjASjR0mnii61Xcq/xEnqp9VBN/jqbdBC8qhAntPjCqix1yx1EprjrI Q2h5WhB5P86gP7s7erFKIRwQtLbeUFsjgrCzxoVvtAbTTthI6q2+PABGPEFxm9r/ SrP/JCLkGSJA4lnCEUiKBRO7IkwkUh1/WYn81Ct7kpwqRn7XTDFb4qz2dIqeADbA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddtledgudejkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvuffkfhggtggujgesthdtredttddtvdenucfhrhhomheptehnughr vghsucfhrhgvuhhnugcuoegrnhgurhgvshesrghnrghrrgiivghlrdguvgeqnecukfhppe eijedrudeitddrvddukedrvdefjeenucfrrghrrghmpehmrghilhhfrhhomheprghnughr vghssegrnhgrrhgriigvlhdruggvnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from intern.anarazel.de (c-67-160-218-237.hsd1.ca.comcast.net [67.160.218.237]) by mail.messagingengine.com (Postfix) with ESMTPA id C25B23060060; Sat, 2 Nov 2019 20:00:18 -0400 (EDT) Date: Sat, 2 Nov 2019 17:00:17 -0700 From: Andres Freund To: Peter Eisentraut Cc: Robert Haas , Tom Lane , pgsql-hackers Subject: Re: Remove configure --disable-float4-byval and --disable-float8-byval Message-ID: <20191103000017.msgpcspscrtg25se@alap3.anarazel.de> References: <15316.1572528990@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hi, On 2019-11-02 08:46:12 +0100, Peter Eisentraut wrote: > On 2019-11-01 15:41, Robert Haas wrote: > > On a related note, why do we store typbyval in the catalog anyway > > instead of inferring it from typlen and maybe typalign? It seems like > > a bad idea to record on disk the way we pass around values in memory, > > because it means that a change to how values are passed around in > > memory has ramifications for on-disk compatibility. > > This sounds interesting. It would remove a pg_upgrade hazard (in the long > run). > > There is some backward compatibility to be concerned about. This change > would require extension authors to change their code to insert #ifdef > USE_FLOAT8_BYVAL or similar, where currently their code might only support > one method or the other. I think we really ought to remove the difference behind macros. That is, for types that could be either, provide macros that fetch function arguments into local memory, independent of whether the argument is a byval or byref type. I.e. instead of having separate #ifdef USE_FLOAT8_BYVALs for DatumGetFloat8(), DatumGetInt64(), ... we should provide that logic in one centralized set of macros. The fact that USE_FLOAT8_BYVAL has to creep into various functions imo is the reasons why people are unhappy about it. One way to do this would be something roughly like this sketch: /* allow to force types to be byref, for testing purposes */ #if USE_FLOAT8_BYVAL #define DatumForTypeIsByval(type) (sizeof(type) <= SIZEOF_DATUM) #else #define DatumForTypeIsByval(type) (sizeof(type) <= sizeof(int)) #endif /* yes, I dream of being C++ once grown up */ #define DefineSmallFixedWidthDatumTypeConversions(type, TypeToDatumName, DatumToTypeName) \ static inline type \ TypeToDatumName (type value) \ { \ if (DatumForTypeIsByval(type)) \ { \ Datum tmp; \ \ /* ensure correct conversion, consider e.g. float */ \ memcpy(&tmp, &value, sizeof(type)); \ \ return tmp; \ } \ else \ { \ type *tmp = (type *) palloc(sizeof(datum)); \ *tmp = value; return PointerGetDatum(tmp); \ } \ } \ \ static inline type \ DatumToTypeName (Datum datum) \ { \ if (DatumForTypeIsByval(type)) \ { \ type tmp; \ \ /* ensure correct conversion */ \ memcpy(&tmp, &datum, sizeof(type)); \ \ return tmp; \ } \ else \ return *(type *) DatumGetPointer(type); \ } \ And then have DefineSmallFixedWidthDatumTypeConversions( float8, Float8GetDatum, DatumGetFloat8); DefineSmallFixedWidthDatumTypeConversions( int64, Int64GetDatum, DatumGetInt64); And now also DefineSmallFixedWidthDatumTypeConversions( macaddr, Macaddr8GetDatum, DatumGetMacaddr8); (there's probably plenty of bugs in the above, it's just a sketch) We don't have to break types / extensions with inferring byval for fixed width types. Instead we can change CREATE TYPE's PASSEDBYVALUE to accept an optional parameter 'auto', allowing to opt in. > > rhaas=# select typname, typlen, typbyval, typalign from pg_type where > > typlen in (1,2,4,8) != typbyval; > > There are also typlen=6 types. Who knew. ;-) There's a recent thread about them :) > > typname | typlen | typbyval | typalign > > ----------+--------+----------+---------- > > macaddr8 | 8 | f | i > > (1 row) > > This might be a case of the above issue: It's easier to just make it pass by > reference always than deal with a bunch of #ifdefs. Indeed. And that's a bad sign imo. Greetings, Andres Freund