Re: functions marked STABLE not allowed to do INSERT - Mailing list pgsql-hackers

From mark@mark.mielke.cc
Subject Re: functions marked STABLE not allowed to do INSERT
Date
Msg-id 20051115033048.GB682@mark.mielke.cc
Whole thread Raw
In response to Re: functions marked STABLE not allowed to do INSERT  (Robert Treat <xzilla@users.sourceforge.net>)
Responses Re: functions marked STABLE not allowed to do INSERT  ("Jim C. Nasby" <jnasby@pervasive.com>)
Re: functions marked STABLE not allowed to do INSERT  (Robert Treat <xzilla@users.sourceforge.net>)
List pgsql-hackers
On Mon, Nov 14, 2005 at 10:02:32PM -0500, Robert Treat wrote:
> > Isn't this the sort of case that Tom just explained as not functioning
> > in 8.1, as the STABLE functions, and all functions called by the
> > STABLE functions will use the snapshot that is used at the time it
> > was called? As in, you do the INSERT, but within the same SELECT
> > statement invoking this 'STABLE' function, it never sees the inserted
> > cached value?
> That's the whole point, it doesn't need to see the cached value as it has 
> already done the look-up the expensive way.  But all subsequent queries will 
> get the value from the cache table, thereby avoiding the expensive query.

Ok. I think I get it. But -- isn't the STABLE definition itself enough to
benefit the same query, without INSERT, assuming appropriate optimization
of STABLE?

The INSERT is only for caching across multiple statements, then,
correct? Or is it to get around a deficiency in the implementation of
STABLE?

> > [ application side caching? ]
> These  are all business logic decsions and as such would be implementation 
> dependent.  Generally the idea is that once the expensive query is done, it's 
> value is unlikely to change. If this were something that would change a lot 
> then it wouldn't exactly be non-volatle would it? 

I think that's the point. Whether the data changes or not in the table, isn't
restricted by the definition of the functions that access the data.

I believe I see your argument, and given a suitable definition of STABLE
(such as only table snapshots being used for the STABLE function, and all
functions invoked by the STABLE function), I can see INSERT being safe
(although perhaps difficult to understand).

I predict wierd scenarios, including a VOLATILE function that normally
expects to be able to update a table, and view the updates
immediately, failing in unexpected ways when called from a STABLE
function. Yuck. It really sounds like something is wrong. Or missing.

I'm scared of it.

Cheers,
mark

-- 
mark@mielke.cc / markm@ncf.ca / markm@nortel.com     __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada
 One ring to rule them all, one ring to find them, one ring to bring them all                      and in the darkness
bindthem...
 
                          http://mark.mielke.cc/



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Long-time 7.4 contrib failure Mac OS X 10.3.8
Next
From: Tim Allen
Date:
Subject: Re: [ADMIN] Major Problem, need help! Can't run our website!