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

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?

In response to

Browse pgsql-hackers by date

  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