Re: the parsing of parameters

Jan Wieck <janwieck(at)yahoo(dot)com> writes:
> Tom Lane wrote:
>> For this particular application, at least, I do not see the value ...
>> in fact this seems more likely to break stuff than help. If the
>> application does not know what the datatypes are supposed to be,
>> how is it going to call the prepared statement?

> Right now using UNKNOWN_OID in that place leads to a parse
> error, what makes me feel absolutely comfortable that there
> will be nobody using it today. So what kind of "break" are
> you talking about?

What I mean is that I don't see how an application is going to use
PREPARE/EXECUTE without knowing the data types of the values it
has to send for EXECUTE. Inside SPI you could maybe do it, since
the calling code can examine the modified argtype array, but there
is no such back-communication channel for PREPARE. This holds
for both textual and binary kinds of EXECUTE: how do you know what
you are supposed to send?

>> You could possibly get away with that for a textual interface ("always
>> pass quoted literals"), but it would surely destroy any chance of having
>> a binary protocol for passing parameters to prepared statements.

> Right. And BTW, how do you propose that the client
> application passes the values in binary form anyway?

Same way as binary cursors work today, with the same ensuing platform
and version dependencies. Maybe someday we'll improve on that, but
that's a different project from supporting PREPARE/EXECUTE.

> I think the backend is the only one who can convert into it's
> personal, binary format. Wouldn't anything else lead to
> security holes?

Good point; might need to restrict the operation to superusers.

> There are DB interfaces that allow a generic application to
> get a description of the result set (column names, types)
> even before telling the data types of all parameters.

> Our ODBC driver for example has it's own more or less
> complete SQL parser to deal with that case! I don't see THAT
> implementation very superior compared to the ability to ask
> the DB server for a guess. I thought that this PREPARE
> statement will be used by such interfaces in the future, no?

Hmm. So your vision of PREPARE would allow the backend to reply
with a list of parameter types. How would you envision that working
exactly?

regards, tom lane