Re: Temp Tables & Connection Pooling

Gerald Gutierrez wrote:

> At 12:48 PM 3/2/2001 -0800, David Olbersen wrote:
> >On Fri, 2 Mar 2001, Gerald Gutierrez wrote:
> >
> >->Recently I wanted to implement Dijkstra's algorithm as a stored procedure,
> >->and finding that PL/PGSQL cannot return record sets, I thought about using
> >->a temporary table for the results. If tempoary tables are session-specific,
> >->however, then wouldn't connection pooling make it unusable since the table
> >->might "disappear" from one query to the next? What are alternative
> >->approaches to implementing Dijkstra's algorithm inside the database?
> >
> ><newbie>
> >Wouldn't a VIEW do what you want?
> ></newbie>
>
> No it wouldn't. Executing Dijkstra would involve executing iterative logic
> on multiple tables and storing intermediate results in a form that can be
> returned to the user but does not affect the actual persistent table schema
> (e.g. a record set, or a temporary table). A view is used to provide a
> simplified or alternative way of looking at a set of data, and cannot
> cannot generally multi-step operation that data prior to returning to the user.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org

This looks like a case for a persistent table where the function would write the
data, along with some kind of session identifier, which would be returned from the
function. Then your could go back to that table with that sessionid and find what
you need. It is kludgey because it has the potential to leave stale data lying
around, you will have to write all kinds of housekeeping code around it.