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
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

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

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!


Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 3 of 5 | next ›
Discussion Overview
grouppgsql-bugs @
postedJan 7, '13 at 6:50p
activeJan 10, '13 at 1:09a



site design / logo © 2021 Grokbase