RE: [HACKERS] time stops within transaction

[Hiroshi Inoue]

> -----Original Message----- > From: Tom Lane [mailto:[EMAIL PROTECTED]] > > > > I just remembered a report from Forest Wilkinson > > about a month ago [SQL] SQL functions not locking > > properly? > > Yes, that was on my to-look-at list too. Not sure if it's related. > As I replied to his posting,the cause is obvious. Because the queries in a function are executed under the same snapshot,SELECT statements never see the changes made by other backends. OTOH SELECT .. FOR UPDATE has a different visiblity from simple SELECT. Yes,SELECT .. FOR UPDATE doesn't guarantee read consistency because it has to acquire a lock on the latest tuples. I recommended to use SELECT .. FOR UPDATE then but it's far from being reasonable. > > Don't we have to distiguish simple procedure calls > > (select func();) and function calls as a part of a query ? > > "select func()" looks like a query to me. I don't see how you are going > to make such a distinction in a useful way. If we had a CALL statement > distinct from function invocation in expressions, then maybe it'd make > sense for that context to act differently. > As I mentioned before,calling functions which have strong side effect e.g. select strong_effect(column1), column2 from table1 where ...; is a problem. IMHO the use of functions should be restricted. Of cource,we have to call(execute)procedures which change the database. Unfortunately we don't have a command to call (execute) functions as procedures currently. Regards. Hiroshi Inoue