> Try issuing the DELETE via EXECUTE --- you're getting burnt by plan> cach=
ing.>=20
Ah yes, that makes sense. So the planner is caching the failed query plan f=
rom when the table didn't exist?
Not a bug after all I guess. Sorry.
=20
I'm moving from an Oracle background, where dropping the table would have m=
arked the function as invalid unless I had used EXECUTE IMMEDIATE, so I wou=
ld have been less likely to make this mistake.
=20
> 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 dro=
pped mid-session, so I shouldn't hit this problem. I only fell over it duri=
ng 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.
=20
Thanks for your help.
=20
Dean.
=20
_________________________________________________________________
100=92s of Music vouchers to be won with MSN Music
https://www.musicmashup.co.uk=