The temporary table should be a private table, accessible only by the
person executing the query, and cleaned up either when the transaction
terminates or PQfinish() is issued, or when the connection to the
associated client terminates...Even indexing wouldn't be necessary,
because the list of Oid's could already be considered an index.
=+=------------------------/\---------------------------------=+=
Igor Natanzon |**| E-mail: igor@sba.miami.edu
=+=------------------------\/---------------------------------=+=
On Sun, 29 Jun 1997, Michael J. Miller Jr. wrote:
> On Sun, 29 Jun 1997, Bruce Momjian wrote:
>
> > > On Sun, 29 Jun 1997, Bruce Momjian wrote:
> > >
> > > In this case couldn't you create a temporary table and return the name
> > > of the table to the client? It could then "cursor" through the temporary
> > > table.
> >
> > Yes, we could, but you would not want to do that all the time because of
> > performance. You would have to determine if that particulary select
> > statement was going to need it.
>
> Well, you'd want to base this on the number of rows returned. For small
> sets it would probably be best to just send it all to the client.
>
> Also, you could implament a low overhead table type to make this work
> better for large data sets. Just do minimal indexing (Probably on
> an oid equiv.) and lay the data out in a way that is quick to write
> and retrieve. For a lot of medium sized datasets you could just do
> this in memory.
>
> Of course I can see some security issues here. You'd either want to
> make it hard for clients other than the one that created the table to
> get to the data, or at the very least make it difficult for the name of
> the temporary table to be guessed.
>
> Mike Miller mke@netcom.com
>
>
------------------------------
