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

From Jan Wieck
Subject Re: the parsing of parameters
Date
Msg-id 200205101705.g4AH5X701720@saturn.janwieck.net
Whole thread Raw
In response to Re: the parsing of parameters  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: the parsing of parameters  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Jan Wieck <janwieck@yahoo.com> writes:
> >     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?
   I  guess there's some sort of statement identifier you use to   refer to something you've prepared. Wouldn't a
function call   returning a list of names or type oid's be sufficient?
 


Jan

--

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




pgsql-hackers by date:

Previous
From: mlw
Date:
Subject: Re: Threads vs processes - The Apache Way (Re: Path to PostgreSQL
Next
From: Tom Lane
Date:
Subject: Re: the parsing of parameters