| From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
|---|---|
| To: | Shianmiin <Shianmiin(at)gmail(dot)com> |
| Cc: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: plpgsql function confusing behaviour |
| Date: | 2011-07-13 13:49:46 |
| Message-ID: | CAHyXU0z6yGeyKiOeTbm=e1EgWk4fgu5xbTUcCfJQ9WnU6bNSsw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Tue, Jul 12, 2011 at 12:10 PM, Shianmiin <Shianmiin(at)gmail(dot)com> wrote:
>
> Merlin Moncure-2 wrote:
>>
>> One proposed solution is to cache plpgsql plans around the search path.
>>
>
> I like the proposed solution, since search_path plays a part when generating
> plpgsql plan, it make sense to be part of the cache.
>
>
> Merlin Moncure-2 wrote:
>>
>> *) use sql functions for portions that float across schemas
>>
>
> Just to clarify, does this mean the sql functions doesn't cache plans like
> plpgsql functions do?
correct. so you could wrap schema dependent bits inside set returning
sql functions.
merlin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Lars Kanis | 2011-07-13 13:59:02 | Using LDAP roles in PostgreSQL |
| Previous Message | Willy-Bas Loos | 2011-07-13 13:29:52 | Re: dirty read from plpgsql |