Re: time stops within transaction
От | Peter Eisentraut |
---|---|
Тема | Re: time stops within transaction |
Дата | |
Msg-id | Pine.LNX.4.21.0010182314290.3228-100000@peter.localdomain обсуждение исходный текст |
Ответ на | Re: time stops within transaction (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane writes: > So? It also says that the choice of exactly when to evaluate now() > is implementation-dependent. Doing so at start of transaction is > an allowed behavior AFAICS. But it's only talking about statements. You can't reuse things that you calculated for previous statements unless it says so. (Of course implementation-dependent means that you can do anything you want to, but let's not go there. :-) > Actually calling time(2) at each use > of now(), which is what the original poster seemed to want, is > clearly *not* an allowed behavior. What this covers is doing things like SELECT CURRENT_TIMESTAMP as "Today", CURRENT_TIMESTAMP + 1 DAY AS "Tomorrow"; But keep in mind that other/correct SQL implementations don't have autocommit, so if you're in some interactive SQL shell and you keep entering select current_timestamp; then it won't ever advance unless you do commits in between. This doesn't make much sense to me, as CURRENT_TIMESTAMP is defined to return the "current time" . The point of a transaction is all data or no data, not all the same data. > I think what you are advocating is recomputing now() at each statement > boundary within a transaction, but that's not as simple as it looks > either. Consider statement boundaries in an SQL function --- the > function is probably being called from some outer statement, so > advancing now() within the function would violate the spec constraint > with respect to the outer statement. Good point. There are probably special rules for SQL functions. I'm not saying that this thing is a priority to me, but it's something to consider. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
В списке pgsql-hackers по дате отправления: