ratq nomr <[EMAIL PROTECTED]> writes:
> 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.
PG 8.3 will behave that way, but there's no support for i
> 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 wou
"Dean" <[EMAIL PROTECTED]> writes:
> If I create a function which relies on the undefined_table exception to test
> if a table exists, it does not behave as expected.
Try issuing the DELETE via EXECUTE --- you're getting burnt by plan
caching.
But actually, do you really want something as destruc
The following bug has been logged online:
Bug reference: 3718
Logged by: Dean
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.5
Operating system: Linux (opensuse 10.3 64-bit) and Windows 2000 SP4
Description:Unexpected undefined_table error after creating/dro
