Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dE7ZL-0001Lh-5l for pgsql-hackers@arkaria.postgresql.org; Fri, 26 May 2017 05:13:47 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1dE7ZK-0006EM-H7 for pgsql-hackers@arkaria.postgresql.org; Fri, 26 May 2017 05:13:46 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dE7ZJ-0006EC-Hh for pgsql-hackers@postgresql.org; Fri, 26 May 2017 05:13:45 +0000 Received: from mail-qk0-x233.google.com ([2607:f8b0:400d:c09::233]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1dE7ZC-0001Be-H6 for pgsql-hackers@postgresql.org; Fri, 26 May 2017 05:13:44 +0000 Received: by mail-qk0-x233.google.com with SMTP id y201so376685qka.0 for ; Thu, 25 May 2017 22:13:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pcorp-us.20150623.gappssmtp.com; s=20150623; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=0R7ORoDw6cck2H+X+12SnUmgKO2Krc1rcgrraKQ3vFo=; b=e0Z4/eStE2sfImJ4ZcreNsRFCdadk/k20JhLA6VHz6yhh8Buj9mSpuobI66XzVWdxP UqSZFuGA4ujb96dKEFBKbbHWiQo6pnFrRoFbSIeoekR/lL7tqmSWGX2n2jzVI4MzYzwj rUYL45nqpjIrIHmEYALhVQ2+aSpQ72rkcEtA5SYttGUNs3zUXVNj9pQMcRZWE8YC305w jKmyn9J0L1rcY1JcsVq5TyA0W/3fpny2iU12Sgs0ZnygTzrGoVxH4T5Vov9gPVyiYPLP lQSnxqyzFfEL8yyVz6do/2b02ufXxOW2jptsOUEEc5mEZRET7TLAK86DOP/vfTiOgDYJ Rr4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=0R7ORoDw6cck2H+X+12SnUmgKO2Krc1rcgrraKQ3vFo=; b=O4+Qz041y1xON/PBECBBjEIryqxZiquxXAIC56lyG4NdbDLrWFV1b7NMWqPgxm2O/l r5vE7+9Ix6veRAnaVN5IWVnm5KlyttM56PY6aHi5I9Fluaagu5yIbW3l8jNSIvkMIlor ppitIq5uQ1mdGU7ArhzyGXpf4CLpm64xGtjIjOJ87cZs2abMMYd+LusOMKMtlNOtzdp3 JHJYYR07dy6GEL+HHJTT/rZCJ9N8etbw/zN0QpKok5bF1OAy0kmJd4w+MvbBsZfLI8tt Lo18Tc6+F9+nOKqJUC5kDaIYqkpMqOAtyrqiFh5oq4QzRWpRFr9Ll4QPnOrqYRfOZwLL FKSA== X-Gm-Message-State: AODbwcB0Vm1WVVzgaxU10JXgxeLOLY4KRMPSVN37l46qbcrYaNZefITb 3PdGHShfqj8UEYE/9Zc= X-Received: by 10.55.212.134 with SMTP id s6mr97479qks.128.1495775616752; Thu, 25 May 2017 22:13:36 -0700 (PDT) Received: from R (50-78-240-110-static.hfc.comcastbusiness.net. [50.78.240.110]) by smtp.gmail.com with ESMTPSA id q34sm6152930qte.44.2017.05.25.22.13.35 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 25 May 2017 22:13:36 -0700 (PDT) From: "Regina Obe" To: "'PostgreSQL-development'" Subject: Re: PostgreSQL 10 changes in exclusion constraints - did something change? CASE WHEN behavior oddity Date: Fri, 26 May 2017 01:13:43 -0400 Message-ID: <000001d2d5de$d8d66170$8a832450$@pcorp.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdLV3tSCOWDqvmKvR3+nW0Qp37Hx0A== Content-Language: en-us X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org > Did something change with how exclusion constraints are handled? I'm trying to troubleshoot a regression we are having with PostGIS raster support. > As best I can guess, it's because exclusion constraints that used to work in past versions are failing in PostgreSQL 10 with an error something like > this: > ERROR: conflicting key value violates exclusion constraint "enforce_spatially_unique_test_raster_columns_rast" > ERROR: new row for relation "test_raster_columns" violates check constraint "enforce_coverage_tile_rast" > Unfortunately I don't know how long this has been an issue since we had an earlier test failing preventing the raster ones from being tested. > Thanks, > Regina I figured out the culprit was the change in CASE WHEN behavior with set returning functions Had a criteria something of the form: CASE WHEN some_condition_dependent_on_sometable_that_resolves_to_false THEN (regexp_matches(...))[1] ELSE ... END FROM sometable; One thing that seems a little odd to me is why these return a record SELECT CASE WHEN strpos('ABC', 'd') > 1 THEN (regexp_matches('a (b) c', 'd'))[1] ELSE 'a' END; SELECT CASE WHEN false THEN (regexp_matches('a (b) c', 'd'))[1] ELSE 'a' END FROM pg_tables; And this doesn't - I'm guessing it has to do with this being a function of the value of table, but it seems unintuitive From a user perspective. SELECT CASE WHEN strpos(f.tablename, 'ANY (ARRAY[') > 1 THEN (regexp_matches('a (b) c', 'd'))[1] ELSE 'a' END FROM pg_tables AS f; Pre-PostgreSQL 10 this would return a row for each record in pg_tables Thanks, Regina -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers