Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > So, in summary, reasons for the change:
> > more intuitive
> > more standard-compliant
> > more closely matches other db's
>
> I'd give you the first and third of those. As Andrew noted, the
> argument that "it's more standard-compliant" is not very solid.
The standard doesn't say anything about transaction in this regard. I
actually think Oracle is closer to the standard than we are right now.
> > Reasons not to change:
> > PostgreSQL traditional behavior
>
> You've phrased that in a way that makes it sound like the decision
> is a no-brainer. How about
>
> Breaks existing Postgres applications in non-obvious ways
>
> which I think is a more realistic description of the downside.
I had used Andrew's words:
the traditional Postgres behaviour of time "freezing" in transaction.
Yes, "breaking" is a clearer description.
> Also, it seems a lot of people who have thought about this carefully
> think that the start-of-transaction behavior is just plain more useful.
> The fact that it surprises novices is not a reason why people who know
> the behavior shouldn't want it to work like it does. (The behavior of
> nextval/currval for sequences surprises novices, too, but I haven't
> heard anyone claim we should change it because of that.)
No one has suggested a more intuitive solution for sequences, or we
would have discussed it.
> So I think a fairer summary is
>
> Pro:
>
> more intuitive (but still not what an unversed person would
> expect, namely true current time)
> arguably more standard-compliant
What does "arguably" mean? That seems more like a throw-away objection.
> more closely matches other db's (but still not very closely)
Closer!
No need to qualify what I said. It is "more" of all these things, not
"exactly", of course.
> Con:
>
> breaks existing Postgres applications in non-obvious ways
> arguably less useful than our traditional behavior
>
> I've got no problem with the idea of adding a way to get at
> statement-arrival time. (I like the idea of a parameterized version of
> now() to provide a consistent interface to all three functionalities.)
> But I'm less than enthused about changing the existing functions to give
> pride of place to statement-arrival time. In the end, I think that
> transaction-start time is the most commonly useful and safest variant,
> and so I feel it ought to have pride of place as the easiest one to get
> at.
Well, let's see what others say. If no one is excited about the change,
we can just document its current behavior. Oh, I see it is already
documented in func.sgml:
It is quite important to realize that
<function>CURRENT_TIMESTAMP</function> and related functions all return
the time as of the start of the current transaction; their values do not
increment while a transaction is running. But
<function>timeofday()</function> returns the actual current time.
Seems that isn't helping enough to reduce the number of people who are
surprised by our behavior. I don't think anyone would be surprised by
statement time.
What do others think?
--
Bruce Momjian | http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
