> 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
