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

Tom Lane wrote:
> Jan Wieck <janwieck@yahoo.com> writes:
> >     I  have  a little patch that actually allows SPI_prepare() to
> >     use UNKNOWN_OID in the passed in  parameter  type  array  and
> >     put's the choosen datatypes Oid back into there.
>
> >     The   parser  treats  those  parameters  like  single  quoted
> >     literals of unknown type and chooses what would be  the  most
> >     useful datatype here.
>
> >     Any objections?
>
> 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?
 

>
> 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?Are you   going to maintain that process  for  backwards  compatibility   when  we change the internal
representationof stuff (like we   want to for numeric) or who? And what  about  byte  ordering?   User defined types?
 
   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?
 

>
> Offhand I'm having a hard time visualizing why you'd want this at
> the SPI_prepare level, either ... what's the application?
   It  propagates up to the SPI level. In fact it is down in the   parser/analyzer.
   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
seeTHAT   implementation very superior compared to the ability  to  ask   the  DB  server  for  a  guess.   I thought
thatthis PREPARE   statement will be used by such interfaces in the future,  no?
 


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #