Re: SetQuerySnapshot, once again - Mailing list pgsql-hackers

From Tom Lane
Subject Re: SetQuerySnapshot, once again
Date
Msg-id 4240.1024496700@sss.pgh.pa.us
Whole thread Raw
In response to Re: SetQuerySnapshot, once again  (Hiroshi Inoue <Inoue@tpf.co.jp>)
List pgsql-hackers
Hiroshi Inoue <Inoue@tpf.co.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


pgsql-hackers by date:

Previous
From: "Tony Griffiths(RA)"
Date:
Subject: Re: Missing library files??
Next
From: Hannu Krosing
Date:
Subject: Re: SQL99 feature list