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 1hiFz9-0002rJ-Hq for pgsql-hackers@arkaria.postgresql.org; Tue, 02 Jul 2019 10:26:03 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hiFz8-0002q4-EJ for pgsql-hackers@arkaria.postgresql.org; Tue, 02 Jul 2019 10:26:02 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hiFz8-0002oM-5g for pgsql-hackers@lists.postgresql.org; Tue, 02 Jul 2019 10:26:02 +0000 Received: from mail-wr1-x441.google.com ([2a00:1450:4864:20::441]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hiFz5-0002fz-Gv for pgsql-hackers@lists.postgresql.org; Tue, 02 Jul 2019 10:26:01 +0000 Received: by mail-wr1-x441.google.com with SMTP id x17so17130838wrl.9 for ; Tue, 02 Jul 2019 03:25:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=RjBZRO5Nux7oIVv1nFgQoxxH6sT7nW1j22zzCPnTILU=; b=uUc1VlZB29cuKjWeaZAsYPtsPvl/iibvg/o9viiPloNUmhoopN90K24I8jP4RKhwh+ xOayo5goQi5v47r3MBpjUK3bSlr0HxDmBAPVDOwEf8lL7nCknZNn+jH5uXjx2zQx1Fl4 fxKkeyA8sbFbcLsP+VToW4yOJWgHRk77k1f5wNfFvYo0Wyzpja+UNVBKZDpbyAEH5Uyo 47W0KgM1bvm8xie6pUCJk31h7//Hrbx4UtNymRIvEy0tBvRrOFrcKREWXi/EOHIpzRiw N9zsBrGFevaYNw/76Vc9RqLInl2AzrjQ2Zc0ZW4izD3f2obBCovms9a0Vh4/97Pl9I77 gtmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=RjBZRO5Nux7oIVv1nFgQoxxH6sT7nW1j22zzCPnTILU=; b=LPfMiWmj5LmQrmLJ+Z5A6EU+/cq70CuOvGToqFVSet7hny1fzLbJ3WbkIdBEty/kca t3F01/T06IjgJepGfaQBlA3Lc2VmO6v4qwvZHl90q4nuph7x3koCr9WgBw5viyolIW3U 7QW+IH6/wCayiEhF5IawgxT04CzvaYGoqP9aIGB04ZwZ409FL/FIC6PrH3tEeapjpftl MYJk2Zyx9XZjwAxOOC81W9N9x2P0f6W+GCrc04BsDXCuux4lpPR1n+8Dnb00EvGeUfvI urx2QUNCz2hiQf8+NUw5vbLtokYVSEeFcm4iDOKTHdnqYSRoqQRABw0s/c4U34FY9Hxh mjIg== X-Gm-Message-State: APjAAAWhMc1wsNMa8IbDQzqDIpeLIvxb4LPu7IJzWN7c9KHomSO+1To7 VNj8ZtUuamF9yHf5ni7rdskyyg== X-Google-Smtp-Source: APXvYqx+jgdiZTyG+HkBOBzaH41nJAdaCICMzEN1pJI5nM2TlCMbzQfQvuAH//jVVRAKr75FoxituA== X-Received: by 2002:adf:e5c2:: with SMTP id a2mr1163944wrn.91.1562063158390; Tue, 02 Jul 2019 03:25:58 -0700 (PDT) Received: from localhost (host86-187-165-65.range86-187.btcentralplus.com. [86.187.165.65]) by smtp.gmail.com with ESMTPSA id r5sm26346328wrg.10.2019.07.02.03.25.57 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Tue, 02 Jul 2019 03:25:57 -0700 (PDT) Date: Tue, 2 Jul 2019 12:25:55 +0200 From: Tomas Vondra To: Dean Rasheed Cc: PostgreSQL Hackers Subject: Re: Choosing values for multivariate MCV lists Message-ID: <20190702102555.qp3smvbwas7f6pc2@development> References: <20190620223548.p22wj7uejbrhkglf@development> <20190622141052.5csokbp3sx577mub@development> <20190623202319.4lcqsi5zc53hktda@development> <20190623234232.xkydftfd7uxexelo@development> <20190625091819.uslpopydrkqm3sdf@development> <20190629130126.53rshkfu2go6atkl@development> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716-1444-295967-dirty List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Mon, Jul 01, 2019 at 12:02:28PM +0100, Dean Rasheed wrote: >On Sat, 29 Jun 2019 at 14:01, Tomas Vondra wrote: >> >> >>>>>However, it looks like the problem is with mcv_list_items()'s use >> >>>>>of %f to convert to text, which is pretty ugly. >> >>>> >> >>>There's one issue with the signature, though - currently the function >> >>>returns null flags as bool array, but values are returned as simple >> >>>text value (formatted in array-like way, but still just a text). >> >>> >> >>IMO fixing this to return a text array is worth doing, even though it >> >>means a catversion bump. >> >> >> Attached is a cleaned-up version of that patch. The main difference is >> that instead of using construct_md_array() this uses ArrayBuildState to >> construct the arrays, which is much easier. The docs don't need any >> update because those were already using text[] for the parameter, the >> code was inconsistent with it. >> > >Cool, this looks a lot neater and fixes the issues discussed with both >floating point values no longer being converted to text, and proper >text arrays for values. > >One minor nitpick -- it doesn't seem to be necessary to build the >arrays *outfuncs and *fmgrinfo. You may as well just fetch the >individual column output function information at the point where it's >used (in the "if (!item->isnull[i])" block) rather than building those >arrays. > OK, thanks for the feedback. I'll clean-up the function lookup. > >> This does require catversion bump, but as annoying as it is, I think >> it's worth it (and there's also the thread discussing the serialization >> issues). Barring objections, I'll get it committed later next week, once >> I get back from PostgresLondon. >> >> As I mentioned before, if we don't want any additional catversion bumps, >> it's possible to pass the arrays through output functions - that would >> allow us keeping the text output (but correct, unlike what we have now). >> > >I think this is a clear bug fix, so I'd vote for fixing it properly >now, with a catversion bump. > I agree. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services