> Try issuing the DELETE via EXECUTE --- you're getting burnt by plan> caching.>
Ah yes, that makes sense. So the planner is caching the failed query plan from when the table didn't exist?
Not a bug after all I guess. Sorry.
I'm moving from an Oracle background, where dropping the table would have marked the function as invalid unless I had used EXECUTE IMMEDIATE, so I would have been less likely to make this mistake.
> But actually, do you really want something as destructive as DELETE> for an existence probe? I'd try> > PERFORM 'bar'::text::regclass;> > and see if that throws an error. (The double cast is important here,> so that you get a runtime lookup not a compile-time one.)> > regards, tom lane
Actually the DELETE was just an artificial example. My real code reads from a temporary table, creating it if necessary. Typically it would not be dropped mid-session, so I shouldn't hit this problem. I only fell over it during testing, when I was getting some quite confusing results. I think it all makes sense if I think about how these query plans are cached.
Thanks for your help.
Dean.
_________________________________________________________________
100’s of Music vouchers to be won with MSN Music
https://www.musicmashup.co.uk