Em 07-01-2013 17:17, Tom Lane escreveu:
> Rodrigo Rosenfeld Rosas<rr.rosas@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.
