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 o
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 see
2013/1/13 Andres Freund :
> On 2013-01-12 15:13:51 -0500, Tom Lane wrote:
>> Andres Freund 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 o
On 2013-01-12 15:13:51 -0500, Tom Lane wrote:
> Andres Freund 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 gu
Em 12-01-2013 18:13, Tom Lane escreveu:
Andres Freund 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 fea
Andres Freund 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 the search path u
Andres Freund wrote:
> On 2013-01-12 14:29:38 -0500, Tom Lane wrote:
>> "Kevin Grittner" 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 so
On 2013-01-12 14:29:38 -0500, Tom Lane wrote:
> "Kevin Grittner" 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 executi
"Kevin Grittner" 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 would
> itsel
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 subs
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?
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 w
Em 07-01-2013 17:17, Tom Lane escreveu:
Rodrigo Rosenfeld Rosas 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;
s
Rodrigo Rosenfeld Rosas 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 transa
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 fro
15 matches
Mail list logo
