Re: SetQuerySnapshot, once again

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

In response to

Responses

Browse pgsql-hackers by date

  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