Re: domain cast in parameterized vs. non-parameterized query - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: domain cast in parameterized vs. non-parameterized query
Date
Msg-id CAFj8pRD4unBF7zneVPQpmBYc8LPBnwViwWTbrNGkOZ33ZLiPVw@mail.gmail.com
Whole thread Raw
In response to Re: domain cast in parameterized vs. non-parameterized query  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers


2017-12-21 15:19 GMT+01:00 Tom Lane <tgl@sss.pgh.pa.us>:
Pavel Stehule <pavel.stehule@gmail.com> writes:
> 2017-12-20 23:41 GMT+01:00 Tom Lane <tgl@sss.pgh.pa.us>:
>> Hm, scratch that --- experimentation shows that the parser still produces
>> a CoerceToDomain node in that case, not a literal of the domain type.

> Why the rewrite doesn't reduce it? Or why parser does it?

Because ALTER DOMAIN can change what would be a valid value.

regression=# create domain myd as int;
CREATE DOMAIN
regression=# create view v1 as select 0::myd as c1;
CREATE VIEW
regression=# select * from v1;
 c1
----
  0
(1 row)

regression=# alter domain myd add check (value > 0);
ALTER DOMAIN
regression=# select * from v1;
ERROR:  value for domain myd violates check constraint "myd_check"

If the view's expression had been reduced to just a Const when it
was stored, we'd not notice that the value is no longer valid for
the domain.  So CoerceToDomain is always postponed till runtime.

ok, I understand

The trick with immutable function should be better documented - now It looks like generally used solution of some optimizer issues related to domain usage.

Regards

Pavel

                        regards, tom lane

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: condition variable cleanup and subtransactions
Next
From: David Rowley
Date:
Subject: Re: [HACKERS] Runtime Partition Pruning