Re: Possible bug on Postgres 12 (CASE THEN evaluated prematurely) -Change of behaviour compared to 11, 10, 9 - Mailing list pgsql-hackers

From Juan Fuentes
Subject Re: Possible bug on Postgres 12 (CASE THEN evaluated prematurely) -Change of behaviour compared to 11, 10, 9
Date
Msg-id 0051B075-67EE-41D9-8BA0-B9A5B35EB499@gmail.com
Whole thread Raw
In response to Re: Possible bug on Postgres 12 (CASE THEN evaluated prematurely) - Change of behaviour compared to 11, 10, 9  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Thanks Tom!

I was just hopping somebody could point out if this kind of issue has been reported before spending 2 days fabricating
asimpler self contained example. 

Best,
Juan

> On 4 Jun 2020, at 16:26, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Juan Fuentes <juanmarianofuentes@gmail.com> writes:
>> As you could see the query includes castings, we noticed testing with Postgres 12 that the castings of the CASE THEN
statement(commented out below) where failing in some cases, of course if you do the INNER JOIN and CASE WHEN first our
expectationis that the value can be casted. 
>
> You're unlikely to get any useful comments on this if you don't provide
> a self-contained example.  The query by itself lacks too many details.
> As an example, one way "t7.value::numeric = 1" could fail despite being
> inside a CASE is if t7 is a view whose "value" column is actually a
> constant.  Flattening of the view would replace "t7.value" with that
> constant, and then constant-folding would cause the failure, and neither
> of those things are prevented by a CASE.  I kind of doubt that that's
> the specific issue here, but I'm not going to guess at what is in your
> thirty-some input tables.
>
>             regards, tom lane




pgsql-hackers by date:

Previous
From: Laurenz Albe
Date:
Subject: Re: what can go in root.crt ?
Next
From: Chapman Flack
Date:
Subject: Re: what can go in root.crt ?