On Sat, Sep 28, 2002 at 11:28:03PM -0400, Bruce Momjian wrote:
>
> OK, we have two db's returning statement start time, and Oracle 8 not
> having CURRENT_TIMESTAMP.
>
> Have we agreed to make CURRENT_TIMESTAMP statement start, and now()
> transaction start? Is this an open item or TODO item?
W
On Sat, Sep 28, 2002 at 11:51:32PM -0400, Bruce Momjian wrote:
> Martijn van Oosterhout wrote:
> > Well, I'd rather it didn't change at all. IMHO it's a feature, not a bug. In
> > any case, if it does get changed we'll have to go through the documentation
> > and work out whether we mean current_t
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Also, we have MSSQL, Interbase, and now Oracle modifying
> CURRENT_TIMESTAMP during the transaction. (The Oracle report just came
> in a few hours ago.)
Weren't you dissatisfied with the specificity of that Oracle report?
> Perhaps we need a vote on t
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Notice the part I highlighted. The time returned is
> > implementation-dependent "during the execution of S". Now, if we do:
>
> > BEGIN;
> > SELECT CURRENT_TIMESTAMP;
> > SELECT CURRENT_TIMESTAMP;
>
> > the time curre
OK, forget system_clock() or clock() timeofday() will do.
Jean-Luc Lachance wrote:
>
> How can you make a difference between now('statement'), and
> now('immediate').
> To me they are the same thing. Why not simply now() for transaction, and
> now('CLOCK') or better yet system_clock() or clock(
How can you make a difference between now('statement'), and
now('immediate').
To me they are the same thing. Why not simply now() for transaction, and
now('CLOCK') or better yet system_clock() or clock() for curent time.
JLL
Josh Berkus wrote:
>
> Tom,
>
> > I'd be happier with the whole thing
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Notice the part I highlighted. The time returned is
> implementation-dependent "during the execution of S". Now, if we do:
> BEGIN;
> SELECT CURRENT_TIMESTAMP;
> SELECT CURRENT_TIMESTAMP;
> the time currently returned for the second
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Now, they are _not_ saying the statement can't have the same time as
> > other statements in the transaction, but I don't see why they would
> > explicitly have to state that.
>
> Allow me to turn that around: given that they clearly
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Now, they are _not_ saying the statement can't have the same time as
> other statements in the transaction, but I don't see why they would
> explicitly have to state that.
Allow me to turn that around: given that they clearly do NOT state that,
how can
Josh Berkus <[EMAIL PROTECTED]> writes:
> Are we still planning on putting the three different versions of now() on the
> TODO? I.e.,
> now('transaction'),
> now('statement'), and
> now('immediate')
> With now() = now('transaction')?
I have no objection to doing that. What seems to be contentio
Josh Berkus wrote:
> Bruce,
>
> > If we change CURRENT_TIMESTAMP to statement time, I don't think we need
> > now(""), but if we don't change it, I think we do --- somehow we should
> > allow users to access statement time.
>
> I'd argue that we need the 3 kinds of now() regardless, just to limi
Bruce,
> If we change CURRENT_TIMESTAMP to statement time, I don't think we need
> now(""), but if we don't change it, I think we do --- somehow we should
> allow users to access statement time.
I'd argue that we need the 3 kinds of now() regardless, just to limit user
confusion. If we set th
Josh Berkus wrote:
>
> Tom,
>
> > I'd be happier with the whole thing if anyone had exhibited a convincing
> > use-case for statement timestamp. So far I've not seen any actual
> > examples of situations that are not better served by either transaction
> > timestamp or true current time. And t
Tom,
> I'd be happier with the whole thing if anyone had exhibited a convincing
> use-case for statement timestamp. So far I've not seen any actual
> examples of situations that are not better served by either transaction
> timestamp or true current time. And the spec is perfectly clear that
>
Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> On Sat, Sep 28, 2002 at 11:51:32PM -0400, Bruce Momjian wrote:
>> Yes, it will split now() and CURRENT_TIMESTAMP. I personally would be
>> happy with STATEMENT_TIMESTAMP, but because the standard requires it we
>> may just have to fix CURRENT_T
Martijn van Oosterhout wrote:
> On Sat, Sep 28, 2002 at 11:28:03PM -0400, Bruce Momjian wrote:
> >
> > OK, we have two db's returning statement start time, and Oracle 8 not
> > having CURRENT_TIMESTAMP.
> >
> > Have we agreed to make CURRENT_TIMESTAMP statement start, and now()
> > transaction s
OK, we have two db's returning statement start time, and Oracle 8 not
having CURRENT_TIMESTAMP.
Have we agreed to make CURRENT_TIMESTAMP statement start, and now()
transaction start? Is this an open item or TODO item?
---
SQL> create table rbr_foo (a date);
Table created.
SQL> begin
2 insert into rbr_foo select sysdate from dual;
[...wait about 10 seconds...]
3 insert into rbr_foo select sysdate from dual;
4 end;
5 /
PL/SQL procedure successfully completed.
SQL> select * from rbr_foo;
A
--
>
> Christoph Haller wrote:
> > Hi pgsql-sql list,
> > I did some testing around tables using a column
> > timestamp with time zone not null default now().
> > I have noticed a valuable feature:
> > As long as being inside a transaction initiated by
> > begin;
> > the return value of the now() fun
On Tue, Sep 24, 2002 at 10:33:51AM +0200, Manfred Koizar wrote:
>
> The people who wrote the specification knew about transactions. If
> they had wanted what you describe above, they would have written:
>
> 3) If a transaction generally contains more than one reference
> to one or more s
On Mon, Sep 23, 2002 at 09:02:00PM +0200, Manfred Koizar wrote:
> On Mon, 23 Sep 2002 13:05:42 -0400, Tom Lane <[EMAIL PROTECTED]>
> >We concluded that the spec defines the behavior as
> >implementation-dependent,
>
> AFAICT the spec requires the returned value to meet two conditions.
>
> C1: If
On Tue, 24 Sep 2002 17:56:51 -0400 (EDT), Bruce Momjian
<[EMAIL PROTECTED]> wrote:
>Can you run a test:
>
> BEGIN;
> SELECT CURRENT_TIMESTAMP;
> wait 5 seconds
> SELECT CURRENT_TIMESTAMP;
>
>Are the two times the same?
MS SQL 7:
begin transaction
insert int
Roland Roberts wrote:
> > "Ross" == Ross J Reedstrom <[EMAIL PROTECTED]> writes:
>
> Ross> Oh, interesting datapoint. Let me get this clear - on
> Ross> oracle, the equivalent of:
>
> Well, I've never gone off to lunch in the middle, but in Oracle 7, I
> had transactions which defini
> "Ross" == Ross J Reedstrom <[EMAIL PROTECTED]> writes:
Ross> Oh, interesting datapoint. Let me get this clear - on
Ross> oracle, the equivalent of:
Well, I've never gone off to lunch in the middle, but in Oracle 7, I
had transactions which definitely took as much as a few minutes t
"Josh Berkus" <[EMAIL PROTECTED]> writes:
> So, if I've got this straight:
> [ snip ]
> ... thus changing only current_timestamp.
Yeah, that's more or less what I was thinking. The argument for
changing current_timestamp seems to be really just spec compliance;
that doesn't apply to now() or tim
Josh Berkus writes:
> now() or now('transaction') returns the transaction timestamp.
> now('statement') returns the statement timestamp now('immediate') returns
> the timestamp at the exact time the function is called.
I like that.
IMHO "the exact time the function is called" is what most people
On Tue, Sep 24, 2002 at 08:05:59AM -0700, Josh Berkus wrote:
>
> This looks fine to me, as a search-and-replace on current_timestamp is
> easy. However, we need to do a better job of warning people about the
> change than we did with interval() to "interval"().
>
> Actually, can I make the
On Tue, Sep 24, 2002 at 10:55:41AM -0400, Roland Roberts wrote:
> > "Martijn" == Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
>
> Martijn> Well, what I would suggest is that when you wrap several
> Martijn> statements into a single transaction with begin/commit,
> Martijn> t
Tom,
> If we leave now() alone then there's no need to create another
> non-spec-compliant syntax like 'transaction_timestamp', either.
> (I really don't want to see us do that, because without parens
> it would mean making a new, not-in-the-spec fully-reserved word.)
So, if I've got this straig
> "Martijn" == Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
Martijn> Well, what I would suggest is that when you wrap several
Martijn> statements into a single transaction with begin/commit,
Martijn> the whole lot could be considered a single statement
Martijn> (since th
Manfred Koizar <[EMAIL PROTECTED]> writes:
> On Mon, 23 Sep 2002 13:36:59 -0700, Josh Berkus <[EMAIL PROTECTED]>
> wrote:
>> Ideally, since we get this question a lot, that a compile-time or
>> execution-time switch to change the behavior of current_timestamp
>> contextually would be nice.
> Ye
>
> Christoph Haller wrote:
> > Hi pgsql-sql list,
> > I did some testing around tables using a column
> > timestamp with time zone not null default now().
> > I have noticed a valuable feature:
> > As long as being inside a transaction initiated by
> > begin;
> > the return value of the now() fun
On Mon, 23 Sep 2002 23:35:13 -0400, Tom Lane <[EMAIL PROTECTED]>
wrote:
>If you want to change 'current_timestamp' to
>conform to a rather debatable reading of the spec, [...]
Well the spec may be debatable, but could you please explain why my
reading of the spec is debatable. The spec says "dur
On Mon, 23 Sep 2002 16:55:48 -0400, Tom Lane <[EMAIL PROTECTED]>
wrote:
>Bruce Momjian <[EMAIL PROTECTED]> writes:
>Here's an example:
>
>CREATE RULE foo AS ON INSERT TO mytable DO
>( INSERT INTO log1 VALUES (... , now(), ...);
> INSERT INTO log2 VALUES (... , now(), ...) );
>
>I think it's impor
On Mon, 23 Sep 2002 13:36:59 -0700, Josh Berkus <[EMAIL PROTECTED]>
wrote:
>I, for one, would judge that the start time of the statement is "during the
>execution"; it would only NOT be "during the execution" if it was a value
>*before* the start time of the statement. It's a semantic argument.
On Tue, 24 Sep 2002 11:19:12 +1000, Martijn van Oosterhout
<[EMAIL PROTECTED]> wrote:
>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 i
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Can I add TODO items for this:
> > o Make CURRENT_TIMESTAMP/now() return statement start time
> > o Add TRANSACTION_TIMESTAMP to return transaction start time
>
> I object to both of those as phrased. If you have already uni
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Can I add TODO items for this:
> o Make CURRENT_TIMESTAMP/now() return statement start time
> o Add TRANSACTION_TIMESTAMP to return transaction start time
I object to both of those as phrased. If you have already unilaterally
determined the
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I was thinking 'transaction_timestamp' for the transaction start time, and
> > current_timestamp for the statement start time. I would equate now()
> > with current_timestamp.
>
> So you want to both (a) invent even more nonstandard
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I was thinking 'transaction_timestamp' for the transaction start time, and
> current_timestamp for the statement start time. I would equate now()
> with current_timestamp.
So you want to both (a) invent even more nonstandard syntax than we
already have
John Hasler wrote:
> Bruce Momjian writes:
> > My point is that our current behavior may not be the most intuitive, and
> > that most people may prefer a change.
>
> I would prefer a change.
Yes, I guess that is my point, that we want to make transaction _and_
statement timestamp values availabl
Bruce Momjian writes:
> My point is that our current behavior may not be the most intuitive, and
> that most people may prefer a change.
I would prefer a change.
--
John Hasler
[EMAIL PROTECTED]
Dancing Horse Hill
Elmwood, Wisconsin
---(end of broadcast)-
Josh Berkus wrote:
>
> Tom, Bruce,
>
> > > A possible compromise is to dissociate now() and current_timestamp,
> > > allowing the former to be start of transaction and the latter to be
> > > start of client command.
> >
> > I was thinking 'transaction_timestamp' for the transaction start time,
Tom, Bruce,
> > A possible compromise is to dissociate now() and current_timestamp,
> > allowing the former to be start of transaction and the latter to be
> > start of client command.
>
> I was thinking 'transaction_timestamp' for the transaction start time, and
> current_timestamp for the sta
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I see what you are saying now --- that even single user statements can
> > trigger multiple statements, so you would have to say transaction start
> > time is time the user query starts. I can see how that seems a little
> > arbitrar
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I see what you are saying now --- that even single user statements can
> trigger multiple statements, so you would have to say transaction start
> time is time the user query starts. I can see how that seems a little
> arbitrary. However, don't we have
I see what you are saying now --- that even single user statements can
trigger multiple statements, so you would have to say transaction start
time is time the user query starts. I can see how that seems a little
arbitrary. However, don't we have separate paths for user queries and
queries sent
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I don't see how we can defend returning the start of the transaction as
> the current_timestamp.
Here's an example:
CREATE RULE foo AS ON INSERT TO mytable DO
( INSERT INTO log1 VALUES (... , now(), ...);
INSERT INTO log2 VALUES (... , now(), ...) );
Josh Berkus wrote:
>
> Bruce,
>
> > I don't see how we can defend returning the start of the transaction as
> > the current_timestamp. In a multi-statement transaction, that doesn't
> > seem very current to me. I know there are some advantages to returning
> > the same value for all queries in
Bruce,
> I don't see how we can defend returning the start of the transaction as
> the current_timestamp. In a multi-statement transaction, that doesn't
> seem very current to me. I know there are some advantages to returning
> the same value for all queries in a transaction, but is that value
Josh Berkus wrote:
> I, for one, would judge that the start time of the statement is "during the
> execution"; it would only NOT be "during the execution" if it was a value
> *before* the start time of the statement. It's a semantic argument.
>
> The spec is, IMHO, rather vague on how this wou
Manfred,
> 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 betwee
On Mon, 23 Sep 2002 13:05:42 -0400, Tom Lane <[EMAIL PROTECTED]>
wrote:
>Manfred Koizar <[EMAIL PROTECTED]> writes:
>> This has been discussed before and I know I'm going to get flamed for
>> this, but IMHO having now() (which is a synonym for CURRENT_TIMESTAMP)
>> return the start time of the cur
53 matches
Mail list logo
