Skip site navigation (1) Skip section navigation (2)

Re: By Passed Domain Constraints

From: Robert Perry <rlperry(at)lodestonetechnologies(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-interfaces(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: By Passed Domain Constraints
Date: 2005-07-06 17:36:00
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-interfaces

     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(at)lodestonetechnologies(dot)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(at)postgresql(dot)org so that  
> your
>        message can get through to the mailing list cleanly

In response to

pgsql-hackers by date

Next:From: Pavel StehuleDate: 2005-07-06 17:42:41
Subject: Re: User's exception plpgsql
Previous:From: Pavel StehuleDate: 2005-07-06 17:31:18
Subject: Re: User's exception plpgsql

pgsql-interfaces by date

Next:From: Christopher Kings-LynneDate: 2005-07-07 01:23:26
Subject: Re: [HACKERS] By Passed Domain Constraints
Previous:From: Tom LaneDate: 2005-07-06 16:59:47
Subject: Re: libpq and connection failures

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group