On Mon, Sep 23, 2002 at 09:02:00PM +0200, Manfred Koizar wrote: > On Mon, 23 Sep 2002 13:05:42 -0400, Tom Lane <[EMAIL PROTECTED]> > >We concluded that the spec defines the behavior as > >implementation-dependent, > > AFAICT the spec requires the returned value to meet two conditions. > > C1: If a statement contains more than one <datetime value function>, > they all have to return (maybe different formats of) the same value. > > C2: The returned value has to represent a point in time *during* the > execution of the SQL-statement. > > The only thing an implementor is free to choose is which point in time > "during the execution of the SQL-statement" is to be returned, i.e. a > timestamp in the interval between the start of the statement and the > first time when the value is needed.
Well, what I would suggest is that when you wrap several statements into a single transaction with begin/commit, the whole lot could be considered a single statement (since they form an atomic transaction so in a sense they are all executed simultaneously). And hence Postgresql is perfectly compliant. My second point would be: what is the point of a timestamp that keeps changing during a transaction? If you want that, there are other functions that serve that purpose. > I understand that with subselects, functions, triggers, rules etc. it > is not easy to implement the specification. If we can't do it now, we > should at least add a todo and make clear in the documentation that > CURRENT_DATE/TIME/TIMESTAMP is not SQL92/99 compliant. The current definition is, I would say, the most useful definition. Can you give an example where your definition would be more useful? -- Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/ > There are 10 kinds of people in the world, those that can do binary > arithmetic and those that can't. ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
