Hannu Krosing wrote:
Tom Lane kirjutas E, 17.11.2003 kell 02:08:
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 b
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
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.
That would be OK. The wh
Tom Lane kirjutas E, 17.11.2003 kell 02:08:
> 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, whic
On Sun, 17 Nov 2003, Greg Stark wrote:
> 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
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 re
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 provi
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 inte
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() returni
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 p
On Sun, 16 Nov 2003, Tom Lane wrote:
> There isn't any compelling implementation reason when to freeze the
> value of now(). Reasonable options are
> 1. at BEGIN (current behavior)
> 2. at transaction's external creation
> 3. at freezing of transaction snapshot
> #1 and #2 are
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 complet
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.
14 matches
Mail list logo
