On Wed, Jan 11, 2017 at 5:38 PM, Adrian Klaver <adrian.kla...@aklaver.com> wrote:
> Because the tables are known, many different functions can access the >> same tables during a session to manipulate the result set. And, because >> the tables are global the client can see the results easily based on the >> then-current table configuration on the server. >> > > So what makes them temporary as they seem to persist between sessions? The way I read this is that the OP wants to be able to write functions that target temporary tables. These functions all assume that said tables already exist so the functions themselves do not need to be concerned with their management. The OP would like to be able to define these tables as persistent objects in the database catalogs but in practice they behave as any other temporary table would. In effect, upon session startup, these tables would be created automatically by the backend without any client involvement. This seems a bit wasteful in terms of all those session/connections that don't care a whit about said temporary tables...so maybe I'm missing something here in the implementation. I don't see where "call a setup function immediately after connecting" is that big a problem. The client has to declare their intent to use said features - and that declaration causes normal temporary tables to spring into existence. If the process functions are used without doing the first step the user will get an error about relation not found. I suspect there may be search_path or language limitations to this approach but the complaint as written doesn't give enough detail about why our temporary tables are proving insufficient. David J.
