Neil Conway <[EMAIL PROTECTED]> writes:
> An alternative would be to flush dependent plans when the schema search
> path is changed.
I think this would actually be the Wrong Thing. It's certainly a
debatable point --- but the best analogy we have is the behavior of
plpgsql functions in the face of search-path changes, and I think that
most people who have thought about that carefully are in favor of
changing plpgsql functions to follow a search path frozen at function
creation time. The fact that we haven't gotten around to making that
happen isn't an argument for breaking PREPARE in the same way that
plpgsql is broken ;-)
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
