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 1hpc86-0007FB-I3 for pgsql-hackers@arkaria.postgresql.org; Mon, 22 Jul 2019 17:29:42 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hpc85-0000Ve-Ch for pgsql-hackers@arkaria.postgresql.org; Mon, 22 Jul 2019 17:29:41 +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 1hpc85-0000VX-0S for pgsql-hackers@lists.postgresql.org; Mon, 22 Jul 2019 17:29:41 +0000 Received: from mail-qt1-x844.google.com ([2607:f8b0:4864:20::844]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hpc82-00020n-0O for pgsql-hackers@lists.postgresql.org; Mon, 22 Jul 2019 17:29:40 +0000 Received: by mail-qt1-x844.google.com with SMTP id x22so34352972qtp.12 for ; Mon, 22 Jul 2019 10:29:37 -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:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=CVZRda4RfE/3jjtgRjUDMbdFQXr8gx9uFAZW7Lpm/Os=; b=WlBuPRxRvvSnSnpZSgVPVBRGEsouhv4Eg7NtscqA5n5vBuUJpR03xA6JugXL3IMFwY iHvfzTivbcvL21toQiOjtPHbaL9eP3drB/4X0yWqTaStj0QnBGjeZ67u+hdljrWt4yL9 +iJUYd8IdZJYWwPJXbYK+LOqvRhR3C4rIxN4FSKsUlUYFoZCpM+Ynsb/1QWygbKIlS7y UPE978dL3SS9syfrLbJk0Yi3tLLbse81BY6fVozWfBCV7NLvVY8Uh6cH0s+AARxOCI4S oBrDKNdw0tHzID18/4fZUXFs4Xg6WKevffww33qYvFcYLFEKgEDfmCUtKCmzMLlIiVzw m2JQ== 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:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=CVZRda4RfE/3jjtgRjUDMbdFQXr8gx9uFAZW7Lpm/Os=; b=tW/v4oysKS6Ven9wx54fSIh8Hm2qKq/fCJa6Ksk1S61v/OCziRDtUOIZz+zKvPxORS tTzP+ADVbd4sUH4Ibr914O62iu7hMg8ggRhEl3YEoIBhdK7nhGOu6FgetVmRkUSvhAc9 45AyLcwlq8qO8ynInz6Aho0lrb1yuXQab5T1Q5q38KJ3vNK0WWVnhItubPs004sqojn8 KqF5Pk9jwklP6Ta9Y4LyqyTa5xm9Kt3VLfXIDE7LrU1O5+5Tz+YIdVKeEQ15LvlmPrKN fIOFRMzMesjkb8I3fy5rLPDINT9qZ66DcMwHM2P3uwIcOIOd9hKStSkF5X4mOfCpFSh4 bBFQ== X-Gm-Message-State: APjAAAVLuBUkxE3ghyxms80I4VPukkRiP3vIcYjhpb/IWXrgr0e1Q/e1 Wgr3IQUe0VAAimLO9k8mwKJqjg== X-Google-Smtp-Source: APXvYqx40jZlY58k581H7KjP7FvDcH+L+cZc8tb/fjRnpGiuuWGpBaQCgCyQIZo83ulOc93JiHrs1A== X-Received: by 2002:ac8:7104:: with SMTP id z4mr50018784qto.52.1563816575971; Mon, 22 Jul 2019 10:29:35 -0700 (PDT) Received: from nimloth.alvh.no-ip.org ([177.154.139.202]) by smtp.gmail.com with ESMTPSA id q56sm21956479qtq.64.2019.07.22.10.29.35 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Mon, 22 Jul 2019 10:29:35 -0700 (PDT) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id A5172120D50; Mon, 22 Jul 2019 13:29:32 -0400 (-04) Date: Mon, 22 Jul 2019 13:29:32 -0400 From: Alvaro Herrera To: Tom Lane Cc: David Rowley , Jesper Pedersen , Andres Freund , Robert Haas , PostgreSQL Hackers Subject: Re: POC: converting Lists into arrays Message-ID: <20190722172932.GA25586@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <25111.1563807020@sss.pgh.pa.us> User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2019-Jul-22, Tom Lane wrote: > David Rowley writes: > > If we do end up with another function, it might be nice to stay away > > from using "concat" in the name. I think we might struggle if there > > are too many variations on concat and there's a risk we'll use the > > wrong one. If we need this then perhaps something like > > list_append_all() might be a better choice... I'm struggling to build > > a strong opinion on this though. (I know that because I've deleted > > this paragraph 3 times and started again, each time with a different > > opinion.) > > Yeah, the name is really the sticking point here; if we could think > of a name that was easy to understand then the whole thing would be > much easier to accept. The best I've been able to come up with is > "list_join", by analogy to bms_join for bitmapsets ... but that's > not great. So with this patch we end up with: list_union (copies list1, appends list2 element not already in list1) list_concat_unique (appends list2 elements not already in list) list_concat (appends all list2 elements) list_concat_copy (copies list1, appends all list2 elements) This seems a little random -- for example we end up with "union" being the same as "concat_copy" except for the copy; and the analogy between those two seems to exactly correspond to that between "concat_unique" and "concat". I would propose to use the name list_union, with flags being "unique" (or "uniquify" if that's a word, or even just "all" which seems obvious to people with a SQL background), and something that suggests "copy_first". Maybe we can offer a single name that does the four things, selecting the exact semantics with boolean flags? (We can provide the old names as macros, to avoid unnecessarily breaking other code). Also, perhaps it would make sense to put them all closer in the source file. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services