On Mon, Sep 23, 2002 at 09:02:00PM +0200, Manfred Koizar wrote:
> On Mon, 23 Sep 2002 13:05:42 -0400, Tom Lane <tgl@sss.pgh.pa.us>
> >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 <kleptog@svana.org> http://svana.org/kleptog/
> There are 10 kinds of people in the world, those that can do binary
> arithmetic and those that can't.
