Unix Technical Forum

Re: inner join problem with temporary tables

This is a discussion on Re: inner join problem with temporary tables within the Pgsql General forums, part of the PostgreSQL category; --> > This message appears: > > ERROR: relation "t_arti" does not exist > SQL state: 42P01 > Context: SQL ...


Go Back   Unix Technical Forum > Database Server Software > PostgreSQL > Pgsql General

Register FAQ Members List Calendar Search Today's Posts Mark Forums Read
  #1 (permalink)  
Old 04-09-2008, 05:52 PM
PFC
 
Posts: n/a
Default Re: inner join problem with temporary tables


> This message appears:
>
> ERROR: relation "t_arti" does not exist
> SQL state: 42P01
> Context: SQL function "test1"
>
>
> Why it does not work???
> thanks for your help


Because plpgsql functions are compiled on first execution and all queries
are then prepared. All tables are referenced directly in prepared
statements, not by name. Any prepared statement that refers to dropped
tables (even dropped temp tables) is thus unfit for consumption.

This allows queries in plpgsql functions to be extremely fast, but it
isn't smart enough (yet) to recompile functions when a table the function
depends on is dropped.

Just disconnect and reconnect, all prepared plans will be lost, and it
will work. Or issue your queries directly instead of using a function.

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #2 (permalink)  
Old 04-09-2008, 05:52 PM
Alvaro Herrera
 
Posts: n/a
Default Re: inner join problem with temporary tables

PFC wrote:
>
> >This message appears:
> >
> >ERROR: relation "t_arti" does not exist
> >SQL state: 42P01
> >Context: SQL function "test1"
> >
> >
> >Why it does not work???
> >thanks for your help

>
> Because plpgsql functions are compiled on first execution and all
> queries are then prepared. All tables are referenced directly in prepared
> statements, not by name. Any prepared statement that refers to dropped
> tables (even dropped temp tables) is thus unfit for consumption.


This is correct but it's not the problem at hand -- notice how the
error message is not talking about an unknown OID. I think the problem
here is that he is using SELECT INTO, which is different in PL/pgSQL
than what is in plain SQL. I bet using CREATE TABLE AS instead of
SELECT INTO would work.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On
Forum Jump


All times are GMT. The time now is 05:39 AM.


Powered by vBulletin® Version 3.6.5
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
SEO by vBSEO 3.2.0
www.UnixAdminTalk.com