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 1ixnUA-0004Xb-Ms for pgsql-hackers@arkaria.postgresql.org; Sat, 01 Feb 2020 07:46:34 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1ixnU8-0004H4-OE for pgsql-hackers@arkaria.postgresql.org; Sat, 01 Feb 2020 07:46:32 +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 1ixnU8-0004D8-9f for pgsql-hackers@lists.postgresql.org; Sat, 01 Feb 2020 07:46:32 +0000 Received: from mail-wm1-x341.google.com ([2a00:1450:4864:20::341]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1ixnU5-0003fx-TL for pgsql-hackers@lists.postgresql.org; Sat, 01 Feb 2020 07:46:31 +0000 Received: by mail-wm1-x341.google.com with SMTP id t23so10474656wmi.1 for ; Fri, 31 Jan 2020 23:46:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=BIe7USaOxxpcBk6wnyh4hktUjcqhDUEI6MggpojBjN0=; b=HnsryuGN74xB72BMNT/z+nNsvjHW3+DLMlRh+fsZj7beW/5RQIr4WXQbCwFAGj8mrn SNd22aV/BZTP+hOp0LRekSvlQ7sjfAh3JT9xcBcDr2OoTYpmdXUR3E4QlOGJQGYx2wQ/ 8y8C45C7C3TyFIoAFccdDHhxc1SA5hcfRskd3PC3IBlWm8gbO8PEM+NRaKsLfDTAKXM7 XIDqGKIOctCcz23bW0zcMlMZlWT6cFj5O5dGnpaawMklGFjRCKMj1LiZV8RFkLBA+9d6 UeDEgcuU/9qyf7VIpl1DpZBgm+ljodxO90a5XGli4y3qqsQvtfQBuUR3nAgCPDdd5b4m KfvQ== 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; bh=BIe7USaOxxpcBk6wnyh4hktUjcqhDUEI6MggpojBjN0=; b=XQE22/2EpBAt3JBUW7HOGK1m42kyPfVwZFsmRkCXySc5h7zOKUIatouSP/SmjYKVba 5LGZRM3wHfiLQz3mUIdwtPiw+dHq8inXSadQT1Uds2/G3r91BCBgEY2qGOjYieUceBZQ KKocUuTvRhrCzBWrvd6vPNQhT5fN3+fBjiJYAv6VLWYh88pEiFP2x+0beQKLmD52C+uC soAuHFbwdUtn0iYfEnJTQmagYISrptvMO5bnoqjN/laz9mEV4nfbu8Lmyrgrf4jkc0lr w3v8vwJcXgQ7S9JUnUU+AP3uJCnxc4FcJB7MtuTf2TvdvaJVKp/OCQzgn3QAXoKQKbg+ n2HA== X-Gm-Message-State: APjAAAXN5uQleYvxKnGsPh1qakIditL9JITojnVumoYO30ENGiQJ5fMM asD298Q2oI55mKvKP02k/gtYP6NvFZ0= X-Google-Smtp-Source: APXvYqzwes5YjZSZE0j2xRTb6t3Dz4xFLfaX8ozzksfXVWMsUIvYXIFerxNXIaOhzVp4wiuTXbRTVg== X-Received: by 2002:a7b:c7d2:: with SMTP id z18mr16919847wmk.160.1580543188099; Fri, 31 Jan 2020 23:46:28 -0800 (PST) Received: from nol (250.25-246-81.adsl-static.isp.belgacom.be. [81.246.25.250]) by smtp.gmail.com with ESMTPSA id z6sm14199690wrw.36.2020.01.31.23.46.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 31 Jan 2020 23:46:27 -0800 (PST) Date: Sat, 1 Feb 2020 08:46:25 +0100 From: Julien Rouhaud To: Tom Lane Cc: Amit Langote , PostgreSQL Hackers Subject: Re: unsupportable composite type partition keys Message-ID: <20200201074625.GA40017@nol> References: <5361.1576602769@sss.pgh.pa.us> <28160.1576676326@sss.pgh.pa.us> <26766.1576947735@sss.pgh.pa.us> <7782.1577051475@sss.pgh.pa.us> <23583.1580505636@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23583.1580505636@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Fri, Jan 31, 2020 at 04:20:36PM -0500, Tom Lane wrote: > Julien Rouhaud writes: > > On Sun, Dec 22, 2019 at 10:51 PM Tom Lane wrote: > >> While poking at this, I also started to wonder why CheckAttributeType > >> wasn't recursing into ranges, since those are our other kind of > >> container type. And the answer is that it must, because we allow > >> creation of ranges over composite types: > > > While working on regression tests for index collation versioning [1], > > I noticed that the 2nd patch apparently broke the ability to create a > > table using a range over collatable datatype attribute, which we > > apparently don't test anywhere. > > Ugh. > > > AFAICT, this is only a thinko in CheckAttributeType(), where the range > > collation should be provided rather than the original tuple desc one, > > as per attached. I also added a create/drop table in an existing > > regression test that was already creating range over collatable type. > > Looks good, although I think maybe we'd better test the case a little > harder than this. Will tweak that and push -- thanks! Ah, I wasn't sure that additional tests on a table would be worthwhile enough. Thanks for tweaking and pushing!