Re: Migrating an application with Oracle temporary tables - Mailing list pgsql-general

From Laurenz Albe
Subject Re: Migrating an application with Oracle temporary tables
Date
Msg-id 556ca13c06e96fe165ee03d297f42bb405807bed.camel@cybertec.at
Whole thread Raw
In response to RE: Migrating an application with Oracle temporary tables  (Mark Zellers <markz@adaptiveinsights.com>)
Responses Re: Migrating an application with Oracle temporary tables
List pgsql-general
On Thu, 2019-05-02 at 16:55 +0000, Mark Zellers wrote:
> I thought I needed the prototype table to be able to define functions and procedures that refer to the temporary
tablebut do not create it.
 
> 
> Perhaps my assumption that I need the table to exist (whether as a temporary table or as a permanent table) in
> order to define the function/procedure is incorrect.  I'll take a look at that.

You don't need the table to exist at function definition time.
The following works just fine, even if the table does not exist:

CREATE FUNCTION f() RETURNS void LANGUAGE plpgsql AS $$BEGIN PERFORM * FROM notexists; END;$$;

This is because functions are not parsed when they are defined.

> I did find a scenario where this approach does run into trouble.  That is, if the function/procedure is executed
> against the permanent table and then you go to run it against a temporary table.  In that case, I do get the
> wrong answer, and I haven't yet figured out how to reset that without dropping the procedure and re-defining it.
> For my purposes, that is "good enough" -- I can promise not to run such procedures against the temporary table.

Yes, that would cause a problem.

The SQL statement "DISCARD PLANS" should fix the problem.

Yours,
Laurenz Albe

-- 
Cybertec | https://www.cybertec-postgresql.com




pgsql-general by date:

Previous
From: Guntry Vinod
Date:
Subject: RE: Back Slash \ issue
Next
From: Igal Sapir
Date:
Subject: Re: Starting Postgres when there is no disk space