From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: proposal: session server side variables |
Date: | 2016-11-25 16:24:37 |
Message-ID: | CAMsr+YF0G8_FehQyFS8gSfnEer9OPsMOvpfniDJOVGQzJzHzsw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 14 October 2016 at 23:09, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>> but only within the session, right? You're not proposing some kind of
>> inter-backend IPC where one backend sets a session var and another
>> backend accesses it and sees the value set by the first session?
>
> In this moment I propose only local (not shared variables). I hope so access
> can be safe with IMMUTABLE access function.
OK, good. Though I suspect you'll have a hard time with IMMUTABLE
functions and need STABLE.
I don't think it's correct to claim that these vars are immutable,
since that'd allow users to do silly things like build them into index
expressions. Splat.
> Default access function should VOLATILE PARALLEL UNSAFE - but immutable sets
> can be defined and used (and I see a sense of these function, because with
> these function the variables are accessed in query planning time).
I don't really understand the purpose of an immutable variable. It
seems inherently contradictory.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-11-25 17:10:34 | Re: confusing checkpoint_flush_after / bgwriter_flush_after |
Previous Message | Tomas Vondra | 2016-11-25 16:22:45 | Re: confusing checkpoint_flush_after / bgwriter_flush_after |