From: | David Kamholz <lautgesetz(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: domain cast in parameterized vs. non-parameterized query |
Date: | 2017-12-20 22:29:28 |
Message-ID: | CAKuxgJ6i4wQUK6vibJaDfG6KW2XonN10d5oEziH4HY8hekYtAQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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?
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-12-20 22:32:43 | Re: Shouldn't execParallel.c null-terminate query_string in the parallel DSM? |
Previous Message | Tom Lane | 2017-12-20 22:24:03 | Re: domain cast in parameterized vs. non-parameterized query |