From: | Jan Wieck <janwieck(at)yahoo(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jan Wieck <janwieck(at)yahoo(dot)com>, Neil Conway <nconway(at)klamath(dot)dyndns(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: the parsing of parameters |
Date: | 2002-05-10 17:05:33 |
Message-ID: | 200205101705.g4AH5X701720@saturn.janwieck.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Jan Wieck <janwieck(at)yahoo(dot)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(at)Yahoo(dot)com #
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-05-10 17:14:38 | Re: the parsing of parameters |
Previous Message | mlw | 2002-05-10 16:55:42 | Re: Threads vs processes - The Apache Way (Re: Path to PostgreSQL |