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 behaviour.
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 session-based
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 compliant
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
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
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 advance
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 in a
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 default to
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.
True, but the spec
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 to new
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 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
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
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, we
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 same type
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
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
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 *single*
[ 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,
19 matches
Mail list logo
