On Thu, Oct 03, 2002 at 07:09:33PM -0400, Tom Lane wrote:
> statement-arrival time. (I like the idea of a parameterized version of
> now() to provide a consistent interface to all three functionalities.)
I like this, too. I think it'd be probably useful. But. . .
> pride of place to statemen
On Fri, 2002-10-04 at 01:41, Bruce Momjian wrote:
> 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
> CURRENT_TIMESTAMP and r
Oliver Elphick <[EMAIL PROTECTED]> writes:
> I can see that the current behaviour might give surprising results in a
> long running transaction. Surprise could be reduced by giving the time
> of first use within the transaction rather than the start of the
> transaction.
[ cogitates ... ] Hmm,
On Thu, Oct 03, 2002 at 04:18:08PM -0400, Bruce Momjian wrote:
>
> So, we have a couple of decisions to make:
>
> Should CURRENT_TIMESTAMP be changed to "statement arrival time"?
> Should now() be changed the same way?
> If not, should now() and CURRENT_TIMESTAMP return the sam
Andrew Sullivan wrote:
> On Thu, Oct 03, 2002 at 04:18:08PM -0400, Bruce Momjian wrote:
> >
> > So, we have a couple of decisions to make:
> >
> > Should CURRENT_TIMESTAMP be changed to "statement arrival time"?
> > Should now() be changed the same way?
> > If not, should now() and C
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 v
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 st
Thomas Lockhart wrote:
> ...
> > 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.
>
> I think that there is no compelling reason for changing the current
> behavior. There is no *
[ Thread moved to hackers.]
OK, I have enough information from the various other databases to make a
proposal. It seems the other databases, particularly Oracle, record
CURRENT_TIMESTAMP as the time of statement start. However, it isn't the
time of statement start from the user's perspective,
> > 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.
Yes, it sais statement.
Note also, that a typical SELECT only session would not advan
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> Note also, that a typical SELECT only session would not advance
> CURRENT_TIMESTAMP at all in the typical "autocommit off" mode that
> the Spec is all about.
True, but the spec also says to default to serializable transaction
mode. So i
Tom Lane <[EMAIL PROTECTED]> wrote:
> "Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> > Note also, that a typical SELECT only session would not advance
> > CURRENT_TIMESTAMP at all in the typical "autocommit off" mode that
> > the Spec is all about.
>
> True, but the spec also says to d
Michael Paesold wrote:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>
> > "Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> > > Note also, that a typical SELECT only session would not advance
> > > CURRENT_TIMESTAMP at all in the typical "autocommit off" mode that
> > > the Spec is all about.
>
Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > That is a very good point. At least with serializable transactions it
seems
> > perfectly reasonable to return a frozen CURRENT_TIMESTAMP. What do you
think
> > about read-commited level? Can time be commited? ;-)
> > It would be even more surprising t
OK, are we agreed to leave CURRENT_TIMESTAMP/now() alone and just add
now("string")? If no one replies, I will assume that is a yes and I
will add it to TODO.
---
Michael Paesold wrote:
> Bruce Momjian <[EMAIL PROTECTED]>
On Sat, 5 Oct 2002 00:29:03 -0400 (EDT), Bruce Momjian
<[EMAIL PROTECTED]> wrote:
>
>OK, are we agreed to leave CURRENT_TIMESTAMP/now() alone and just add
>now("string")? If no one replies, I will assume that is a yes and I
>will add it to TODO.
So my view of CURRENT_TIMESTAMP not being spec com
Manfred Koizar <[EMAIL PROTECTED]> writes:
> And one last thought: There are applications out there that are not
> written for one specific database backend. Having to replace
> CURRENT_TIMESTAMP by PG-specific now('statement') is just one more
> pain in trying to be portable across different ba
Yes, I agree with you Manfred, but more people _don't_ want it to
change, and like it the way it is, so we will just keep it and add
now("string").
Added to TODO:
* Add now("transaction|statement|clock") functionality
I have attached an SGML patch that explains the issues with
CURRENT_
Hello!
On Sat, 5 Oct 2002, Bruce Momjian wrote:
>
> Yes, I agree with you Manfred, but more people _don't_ want it to
> change, and like it the way it is, so we will just keep it and add
> now("string").
IMHO the best way could be GUC-default/SET session-based variable
controlling the behavio
Yury Bokhoncovich wrote:
> Hello!
>
> On Sat, 5 Oct 2002, Bruce Momjian wrote:
>
> >
> > Yes, I agree with you Manfred, but more people _don't_ want it to
> > change, and like it the way it is, so we will just keep it and add
> > now("string").
>
> IMHO the best way could be GUC-default/SET se
20 matches
Mail list logo
