Re: BUG #18812: Conditional rule: inconsistent check for statement

Hi Tom,

thanks for the fastest and exhaustive answer!

On 15/02/2025 01:55, Tom Lane wrote:
> We get variants of this complaint from time to time, but few of
> them present use-cases that seem compelling enough to justify the
> performance costs of not doing constant-folding.

I think it's the right decision! But...

On 15/02/2025 01:55, Tom Lane wrote:
> PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
>> I've two rules for a view - unconditional INSTEAD (skip) and conditional
>> INSTEAD (always FALSE). But if I trying to insert a type mismatched
data to
>> the view, I've got a type constraint error.
>
> [ shrug... ] The WHERE FALSE condition is evaluated later than it
> would need to be to prevent this error. If we use a value that
> doesn't trigger the error:
>
> =# explain verbose INSERT INTO v (c) VALUES ('testtest');
> QUERY PLAN
> ------------------------------------------------------
> Insert on public.t (cost=0.00..0.01 rows=0 width=0)
> -> Result (cost=0.00..0.01 rows=1 width=14)
> Output: 'testtest'::character varying(10)
> One-Time Filter: false
> (4 rows)
>
> we can see that the "false" is actually applied at runtime, but the
> value coercion happened during planner constant-folding. In general
> the order of application of WHERE clauses is not guaranteed, so
> there's not a good argument that this outcome is wrong.

What do you think about adding the behavior described above (undefined
behavior, generally) to the help?

---
WBR
Boris