Bruce Momjian [EMAIL PROTECTED] writes:
Hannu Krosing wrote:
It would be even better to have now() that returns the time current
transaction is COMMITted as this is the time other backend become aware
of it ;)
True, but implementing that would be very hard.
Son, that was a *joke* ...
Hannu Krosing wrote:
Bruce Momjian kirjutas E, 17.11.2003 kell 02:31:
Defining now() as the first call seems pretty arbitrary to me. I can't
think of any time-based interface that has that API. And what if a
trigger called now() in an earlier query and you didn't even know about
it.
Redirected to -hackers
Neil Conway kirjutas L, 15.11.2003 kell 22:20:
Tom Lane [EMAIL PROTECTED] writes:
(I believe the previous discussion also agreed that we wanted to
postpone the freezing of now(), which currently also happens at
BEGIN rather than the first command after BEGIN.)
Hannu Krosing [EMAIL PROTECTED] writes:
Probably the latest time we can start the transaction is ath the start
of executor step after the first statement in a transaction is planned
and optimized.
The transaction has to exist before it can take locks, so the above
would not fly.
A complete
Hannu Krosing [EMAIL PROTECTED] writes:
For me, the start of transaction is not about time, but about grouping
a set of statements into one. So making the exact moment of start be
the first statement that actually does something with data seems
perfectly reasonable.
This might be a perfectly
Tom Lane [EMAIL PROTECTED] writes:
That's defensible when the user issued the BEGIN himself. When the
BEGIN is coming from some interface library's autocommit logic, it's
a lot less defensible. If you consult the archives, you will find
actual user complaints about why is now() returning a
Neil Conway [EMAIL PROTECTED] writes:
Hmmm... I agree this behavior isn't ideal, although I can see the case
for viewing this as a mistake by the application developer: they are
assuming that they know exactly when transactions begin, which is not
a feature provided by their language
Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
Hmmm... I agree this behavior isn't ideal, although I can see the case
for viewing this as a mistake by the application developer: they are
assuming that they know exactly when transactions begin, which is not
a feature provided by
Neil Conway [EMAIL PROTECTED] writes:
What does BEGIN actually do now, from a user's perspective?
I think you're thinking about this all wrong. BEGIN doesn't do anything.
It's not a procedural statement, it's a declaration. It declares that the
block of statements form a transaction so reads
