Re: Add notification on BEGIN ATOMIC SQL functions using temp relations

Jim Jones <jim.jones@uni-muenster.de> writes:
> While playing with v9 I realised that this issue also affects
> non-temporary tables when they use temporary types (in pg_temp)::

Right.  Really the dependency-on-temp-type scenario affects a ton of
object types: aggregates, casts, domains, operators, you name it.

> The column was dropped because it depended on a temporary type. IMO this
> is a bit more serious than the previous case, since it silently leads to
> data loss. I believe that at least a NOTICE would add some value here.

Meh.  It's been like that for a very long time, yet I can recall
approximately zero field complaints about it.  There must have
been one about the view case, sometime in the paleolithic era,
and we had one about functions which prompted the present thread.
But not other cases.

I'm disinclined to add cycles for such tests without actual field
complaints.  While I argued upthread that collectDependenciesOfExpr()
is pretty cheap, it's harder to make that case for find_temp_object(),
since that necessarily involves at least two syscache lookups per
dependency.  So if we add more of those, I'd like to be confident
that we're solving a problem that real users have.

I'll go ahead and add some test cases to the v9 patch and push it.
We already have nearly-good-enough test coverage for the view case,
but I think it'd be nice to have a test for a dependency that the
old code wouldn't have found, perhaps nextval-on-a-temp-sequence.

            regards, tom lane