Neil Conway <[EMAIL PROTECTED]> writes:
> ... By not well-defined, I meant that
> if the user is changing GUC variables on the fly, they can't rely on
> their prepared query being planned under any particular datestyle (or
> search path, etc.), since they can't really predict when replanning will
> take place (e.g. an sinval overflow could occur spontaneously and cause
> all cached plans to be invalidated). This is similar to how search_path
> and pl/pgsql works right now -- we'll use the search_path in effect when
> the query is planned, which may or may not be what the user would expect.
As soon as we have the replanning mechanism, I think that there will be
considerable pressure to use it to ensure that search_path changes and
so on *do* behave consistently.
The question here is what does "consistently" mean.
My first thought is that the best idea in most scenarios would be to
associate a search_path value with each function, rather than allowing
the meaning of queries within each function to vary depending on the
caller's search_path. We have seen one or two examples where the user
would rather have the other behavior --- but they are surely a small
minority.
I'm not sure though that I care to extend that thought to each
individual GUC variable ... even though it's surely true that changes
in e.g. datestyle could break a particular function. The contrary
argument is that GUC variables are useful just because they represent
a single place to set some behavior, and having to fix the values
associated with N different functions would be a nightmare outweighing
the benefits of stable values for individual functions.
Any thoughts on how this stuff "ought to" behave?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
