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

Поиск
Список
Период
Сортировка
От David Kamholz
Тема Re: domain cast in parameterized vs. non-parameterized query
Дата
Msg-id CAKuxgJ6i4wQUK6vibJaDfG6KW2XonN10d5oEziH4HY8hekYtAQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: domain cast in parameterized vs. non-parameterized query  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
You might consider whether you can write 'spa-000'::uid explicitly in your
query; that results in immediate application of the domain coercion, so
that the planner no longer sees that as a run-time operation it has to
avoid.

I should have mentioned that I tried an explicit cast and found that 'spa-000' and 'spa-000'::uid produce identical results. As far as I can tell, there is *no* way to get the planner to constant-fold in this case without using prepared statements. 
 
It's tempting to wonder whether we could somehow constant-fold
CoerceToDomain, at least in the estimation case, but I'm afraid that
would lead to domain constraint failures that would not necessarily occur
at runtime.  Or we could skip the domain check for estimation purposes,
but then we're possibly feeding a value that fails the domain check to a
function that might not work right under such conditions.  So on the
whole I'm afraid to monkey with that decision.

OK, I can see how that makes sense. But shouldn't an explicit cast still work? 

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: domain cast in parameterized vs. non-parameterized query
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Shouldn't execParallel.c null-terminate query_string in theparallel DSM?