Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Re: [INTERFACES] retrieving varchar size

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us (Tom Lane)
Cc: pgsql-hackers(at)postgreSQL(dot)org, pgsql-interfaces(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Re: [INTERFACES] retrieving varchar size
Date: 1998-04-26 23:41:33
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-interfaces
> Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> writes:
> > My idea is to make a PQexecv() just like PQexec, except it returns an
> > array of results, with the end of the array terminated with a NULL,
> > [ as opposed to my idea of returning PGresults one at a time ]
> Hmm.  I think the one-at-a-time approach is probably better, mainly
> because it doesn't require libpq to have generated all the PGresult
> objects before it can return the first one.
> Here is an example in which the array approach doesn't work very well:
> 	QUERY: copy stdin to relation ; select * from relation
> What we want is for the application to receive a PGRES_COPY_IN result,
> perform the data transfer, call PQendcopy, and then receive a PGresult
> for the select.
> I don't see any way to make this work if the library has to give back
> an array of results right off the bat.  With the other method, PQendcopy
> will read the select command's output and stuff it into the (hidden)
> result queue.  Then when the application calls PQnextResult, presto,
> there it is.  Correct logic for an application that submits multi-
> command query strings would be something like

OK, you just need to remember to throw away any un-called-for results if
they do another PQexec without retrieving all the results returned by
the backend.

> Another thought: we might consider making PQexec return as soon as it's
> received the first query result, thereby allowing the frontend to
> overlap its processing of this result with the backend's processing of
> the rest of the query string.  Then, PQnextResult would actually read a
> new result (or the "I'm done" message), rather than just return a result
> that had already been stored.  I wasn't originally thinking of
> implementing it that way, but it seems like a mighty attractive idea.
> No way to do it if we return results as an array.


> Well, we can settle for having PQendcopy return 0 or 1 as it does now.
> It's not quite as clean as having it return a real PGresult, but it's
> probably not worth breaking existing apps just to improve the
> consistency of the API.  It'd still be possible to queue up subsequent
> commands' results (if any) in the result queue.


> > Again, if we clearly document the change, we are far enough from 6.4
> > that perl and other people will handle the change by the time 6.4 is
> > released.  Changes the affect user apps is more difficult.
> I have mixed feelings about this particular item.  It would make the
> protocol more robust, but it's not clear that the gain is worth the
> risk of breaking any existing apps.  I'm willing to drop it if no one
> else is excited about it.

It's up to you.

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

In response to


pgsql-hackers by date

Next:From: Michael HirohamaDate: 1998-04-27 00:55:54
Subject: Re: retrieving varchar size
Previous:From: Tom LaneDate: 1998-04-26 23:13:28
Subject: Re: [HACKERS] Re: [INTERFACES] retrieving varchar size

pgsql-interfaces by date

Next:From: Henk VergonetDate: 1998-04-26 23:56:54
Subject: unsubscribe
Previous:From: Tom LaneDate: 1998-04-26 23:13:28
Subject: Re: [HACKERS] Re: [INTERFACES] retrieving varchar size

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group