Re: [GENERAL] Means to emulate global temporary table - Mailing list pgsql-general

From Ian Lewis
Subject Re: [GENERAL] Means to emulate global temporary table
Date
Msg-id CAMoTSQ04=gFXJs7Pv1jK0cqVJ6DNsFcjt2LqDruyZ8+61HxjWg@mail.gmail.com
Whole thread Raw
In response to Re: [GENERAL] Means to emulate global temporary table  ("David G. Johnston" <david.g.johnston@gmail.com>)
List pgsql-general
On Wed, Jan 11, 2017 at 4:38 PM, Adrian Klaver <adrian.klaver@aklaver.com> wrote:

So what makes them temporary as they seem to persist between sessions?

They are temporary in the sense that the content of the table is per-session, just as a local temporary table would be. That is, each session has its own independent data set. But, the table is defined and accessible within the schema as a normal table would be.
 
While efficiency is not an issue in our usage, on our current server, they are very efficient because they do not need to handle locking as a normal table would do because only one session can access the data.

 

That can be handled with SECURITY DEFINER:

 

https://www.postgresql.org/docs/9.6/static/sql-createfunction.html

"EXTERNAL] SECURITY INVOKER

[EXTERNAL] SECURITY DEFINER

    SECURITY INVOKER indicates that the function is to be executed with the privileges of the user that calls it. That is the default. SECURITY DEFINER specifies that the function is to be executed with the privileges of the user that created it.

    The key word EXTERNAL is allowed for SQL conformance, but it is optional since, unlike in SQL, this feature applies to all functions not only external one

 

I will look at this in more detail, but, on first reading, I do not quite see how it helps. 

 
Ian Lewis (www.mstarlabs.com)
 

pgsql-general by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: [GENERAL] Means to emulate global temporary table
Next
From: John R Pierce
Date:
Subject: Re: [GENERAL] Means to emulate global temporary table