Re: By Passed Domain Constraints

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
>