Re: domain cast in parameterized vs. non-parameterized query
От | Tom Lane |
---|---|
Тема | Re: domain cast in parameterized vs. non-parameterized query |
Дата | |
Msg-id | 11221.1513865956@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: domain cast in parameterized vs. non-parameterized query (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: domain cast in parameterized vs. non-parameterized query
Re: domain cast in parameterized vs. non-parameterized query |
Список | pgsql-hackers |
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. regards, tom lane
В списке pgsql-hackers по дате отправления: