Re: the parsing of parameters

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Jan Wieck <janwieck(at)yahoo(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Neil Conway <nconway(at)klamath(dot)dyndns(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: the parsing of parameters
Date: 2002-05-28 01:16:59
Message-ID: 200205280116.g4S1Gxe24388@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jan Wieck wrote:
> Tom Lane wrote:
> > Jan Wieck <janwieck(at)yahoo(dot)com> writes:
> > >> 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?
> >
> > I was thinking of having the type names returned unconditionally,
> > perhaps like a SELECT result (compare the new behavior of EXPLAIN).
> > But if we assume that this won't be a commonly used feature, maybe
> > a separate inquiry operation is better.
>
> I wouldn't mind. One way or the other is okay with me.
>
> Reminds me though of another feature we should have on the
> TODO. INSERT/UPDATE/DELETE ... RETURNING ...

TODO already has:

o Allow INSERT/UPDATE ... RETURNING new.col or old.col; handle
RULE cases (Philip)

Do we need DELETE too?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Neil Conway 2002-05-28 01:17:31 Re: [HACKERS] Re : Solaris Performance - 64 bit puzzle
Previous Message Tatsuo Ishii 2002-05-28 01:07:46 Re: pgstatindex