From: Tom Lane <tgl@sss.pgh.pa.us>
To: drtr0jan@yandex.ru
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18812: Conditional rule: inconsistent check for statement
Date: Fri, 14 Feb 2025 17:55:14 -0500
Message-ID: <3914796.1739573714@sss.pgh.pa.us> (raw)
In-Reply-To: <18812-565809b4823e2b68@postgresql.org>
References: <18812-565809b4823e2b68@postgresql.org>
PG Bug reporting form <noreply@postgresql.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.
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.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, drtr0jan@yandex.ru, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18812: Conditional rule: inconsistent check for statement
In-Reply-To: <3914796.1739573714@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox