*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
droppi
pá 3. 5. 2019 v 8:19 odesílatel Laurenz Albe
napsal:
> On Thu, 2019-05-02 at 16:55 +, Mark Zellers wrote:
> > I thought I needed the prototype table to be able to define functions
> and procedures that refer to the temporary table but do not create it.
> >
> > Perhaps my assumption that I nee
On Thu, 2019-05-02 at 16:55 +, Mark Zellers wrote:
> I thought I needed the prototype table to be able to define functions and
> procedures that refer to the temporary table but do not create it.
>
> Perhaps my assumption that I need the table to exist (whether as a temporary
> table or as a
lbe
Sent: Thursday, May 2, 2019 1:00 AM
To: Mark Zellers ;
pgsql-general@lists.postgresql.org
Subject: Re: Migrating an application with Oracle temporary tables
Mark Zellers wrote:
> One of the issues I have run into in migrating from Oracle to PostgreSQL is
> the difference in tempor
Hi
What I am not clear on is what the rules are as to when a
> function/procedure is effectively recompiled. Is there a danger that.
> assuming the temporary table is created for a session that one session
> might see another session's data due to the procedure having effectively
> compiled the t
Mark Zellers wrote:
> One of the issues I have run into in migrating from Oracle to PostgreSQL is
> the difference in temporary table behavior.
> I've come up with what I think is a cunning plan, but I wonder if anyone with
> more PostgreSQL understanding can shoot holes in it.
>
> Oracle defin
