Tom
Thank you very much. This sounds like my problem exactly. I
personally, feel that the change you have described is the right way
to go for PostgreSQL. But, since the thing that I expected to work
does not and would with your suggested change I guess that my opinion
is pretty predictable.
B.T.W. Using PQexec instead of PQexecParams also solves my
problem. But, that is not a surprise either given your assessment of
the problem. Since all of the C++ code in my project ends up calling
a single function that calls PQexecParams (this was done to
centralize the conversion of PostgreSQL exceptions to out own
internal exception classes) I think it is going to be easier for us
to make this function dynamically build a non parameterized query.
But, I still appreciate your advice on a work around and I am holding
it as my plan B.
Thanks again
Robert Perry
On Jul 6, 2005, at 12:05 PM, Tom Lane wrote:
> Robert Perry <rlperry@lodestonetechnologies.com> writes:
>
>> I have also been bitten by the problem you are describing. But,
>> that one is a problem even when called from psql if I am not
>> mistaken. Does psql not use pqlib? Perhaps it is something about
>> PQexecParams that is the problem. I will test in a little while.
>>
>
> [ thinks about it... ] If you've declared the function input
> parameter
> as a domain type and then write a parameterized query like
> ... function($1) ...
> and don't specify any particular datatype for the parameter symbol,
> I think the backend will infer the domain type as the parameter type.
> Which would also allow bypassing the domain checks.
>
> You could work around this by explicitly specifying the parameter
> type as text or varchar or whatever the domain's base type is.
> I wonder though if we oughtn't change the backend so that the inferred
> type of a parameter symbol is never a domain, but the domain's base
> type. That would force the proper application of CoerceToDomain
> inside
> the constructed query parsetree.
>
> regards, tom lane
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that
> your
> message can get through to the mailing list cleanly
>
