Re: domain cast in parameterized vs. non-parameterized query

2017-12-21 15:19 GMT+01:00 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:

> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> > 2017-12-20 23:41 GMT+01:00 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
>