Hi Tom,
Why not implement a session/database option to use (or not) the replanning
of such functions. This would allow existing PG clusters to behave as they
historically did, and would simultaneously allow users who want to have
benefit of dynamically changing search_path inside a function to
Just adding in my two cents...
At my last company we had several hundred stored procedures which all set a
search path dynamically based on an input argument prior to running any
queries. The current behavior is very alarming and challenging to
consistently workaround.
Would be very happy to
Em 12-01-2013 18:13, Tom Lane escreveu:
Andres Freundand...@2ndquadrant.com writes:
On 2013-01-12 14:29:38 -0500, Tom Lane wrote:
I think that the alternative most likely to succeed is to consider any
change in the active value of search_path as forcing replanning of
cached plans.
I guess it
2013/1/13 Andres Freund and...@2ndquadrant.com:
On 2013-01-12 15:13:51 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2013-01-12 14:29:38 -0500, Tom Lane wrote:
I think that the alternative most likely to succeed is to consider any
change in the active value of
Rodrigo Rosenfeld Rosas wrote:
I'm curious though. Why wouldn't this behavior be considered a
bug? Is there any link to previous discussions about this subject
that I could read?
A plpgsql function generates a plan on initial execution which
chooses which particular tables are used. On
Kevin Grittner kgri...@mail.com writes:
To try to get your function code to work as you expect, the
language would essentially need to identify which statements could
be pre-planned, and which would needed to be treated as raw source
on each execution. That would be tricky to implement, and
On 2013-01-12 14:29:38 -0500, Tom Lane wrote:
Kevin Grittner kgri...@mail.com writes:
To try to get your function code to work as you expect, the
language would essentially need to identify which statements could
be pre-planned, and which would needed to be treated as raw source
on each
Andres Freund wrote:
On 2013-01-12 14:29:38 -0500, Tom Lane wrote:
Kevin Grittner kgri...@mail.com writes:
To try to get your function code to work as you expect, the
language would essentially need to identify which statements could
be pre-planned, and which would needed to be treated as raw
Andres Freund and...@2ndquadrant.com writes:
On 2013-01-12 14:29:38 -0500, Tom Lane wrote:
I think that the alternative most likely to succeed is to consider any
change in the active value of search_path as forcing replanning of
cached plans.
I guess it wouldn't really be feasible to keep
Rodrigo Rosenfeld Rosas wrote:
Tom Lane wrote:
There have been discussions about changing that
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?
No, there has been discussion about
Em 09-01-2013 20:09, Kevin Grittner escreveu:
Rodrigo Rosenfeld Rosas wrote:
Tom Lane wrote:
There have been discussions about changing that
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?
I didn't want to report the bug using the form before confirming it here.
Here is a gist of what I'm trying:
https://gist.github.com/49fcc8c4a5a810f66833#file-cleanup-sql
The relevant part being this:
old_path := pg_catalog.current_setting('search_path');
raise notice 'setting search_path
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
Em 07-01-2013 17:17, Tom Lane escreveu:
Rodrigo Rosenfeld Rosasrr.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
14 matches
Mail list logo
