From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: SetQuerySnapshot, once again |
Date: | 2002-06-19 14:25:00 |
Message-ID: | 4240.1024496700@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> writes:
>> I do not like the idea of treating the first select in a function
>> differently from the rest. And such a rule wouldn't let you build
>> guaranteed-stable functions anyway;
> AFAIK there has been no analysis where we can get *stable*
> functions. As far as I see, we can expect SELECT-only functions
> to be *stable* if and only if they are surrounded by SELECT-only
> *stable* functions.
This idea might be a bit off-the-wall, but how about:
1. If a plpgsql function is declared immutable or stable, then all its
queries run with the same snapshot *and* CommandCounterId as prevail
in the calling query. Probably we should disallow it from making any
updating queries, too; allow only SELECTs.
2. If it's declared volatile (the default), then snapshot and
CommandCounterId are both updated for each query in the function,
including the first one.
So the default behavior would be equivalent to issuing the same queries
interactively, which I think is a good default. The non-default
behavior would allow truly stable functions to be built.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Lockhart | 2002-06-19 14:42:43 | Re: SQL99 feature list |
Previous Message | Thomas Lockhart | 2002-06-19 14:19:15 | Re: ecpg and bison again |