Re: the parsing of parameters - Mailing list pgsql-hackers

Jan Wieck <janwieck@yahoo.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