Em 07-01-2013 17:17, Tom Lane escreveu:
Rodrigo Rosenfeld Rosas<rr.ro...@gmail.com> writes:perform pg_catalog.set_config('search_path', templ, true); ... select count(distinct transaction_id) from public.transaction_condition into temp_count; raise notice '% remaining transactions in public!', temp_count; select count(distinct transaction_id) from transaction_condition into temp_count;If this is inside a plpgsql function that's been executed more than once, the SELECTs would have plans that were cached the first time around, so that what would matter is the search_path that prevailed during the first execution. There have been discussions about changing that but we wouldn't treat it as a back-patchable bug fix, because it would almost certainly break things for somebody.
So, Tom, if I understand it correctly, you do consider it a bug but you don't want to backport a fix because it might break existent behavior in some dbs, right?
But it is not clear to me if you're willing to fix it for 9.2.3 for instance?
It is likely I'll be creating lots of functions to perform the same operations in different schemas as my application is being designed to handle multiple field templates using separate schemas and the application will switch what templates are used based on current_path but lots of database migrations (not sure if you know what I mean for that, but I'm using Rails web framework terminology here) will perform the same changes to the database for each of the supported schemas/templates.
So, I'd really like this behavior to be fixed in future versions of PG if possible.
What is your opinion on the subject? Thanks for the prompt answer! Cheers, Rodrigo. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
