The attached patch removes or minimizes some documentation mentions of
backward compatibility for release 7.2 and earlier. I have not altered
any mentions of release 7.3 or later. The release notes were not
modified, so the changes are still documented, just not in the main
docs.
--
Bruce
[ Sorry for the two copies, Bruce: I forgot to CC the list previously ]
On Mon, 2006-03-20 at 13:57 -0500, Bruce Momjian wrote:
The attached patch removes or minimizes some documentation mentions of
backward compatibility for release 7.2 and earlier.
I don't think it's a net win to get rid of
I hBrendan Jurd wrote:
On 8/7/05, Brendan Jurd [EMAIL PROTECTED] wrote:
Hi all,
I propose to add an internal function gettime() that transparently
returns the current system time, as a timestamptz with maximum
precision.
Rather than applying the above patch, I have implemented this
Bruce Momjian wrote:
Rather than applying the above patch, I have implemented this TODO
with the attached patch:
* Add transaction_timestamp(), statement_timestamp(),
clock_timestamp() functionality
The most common complaint that I recall is that current_timestamp
returns the
Neil Conway [EMAIL PROTECTED] writes:
I don't think it's a net win to get rid of this text, as it describes
useful alternatives to the GUC variable:
I was about to object to some other parts of the patch on the same
grounds, in particular the changes to ddl.sgml and maintenance.sgml,
and the
Peter Eisentraut wrote:
Bruce Momjian wrote:
Rather than applying the above patch, I have implemented this TODO
with the attached patch:
* Add transaction_timestamp(), statement_timestamp(),
clock_timestamp() functionality
The most common complaint that I recall is that
Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
I don't think it's a net win to get rid of this text, as it describes
useful alternatives to the GUC variable:
I was about to object to some other parts of the patch on the same
grounds, in particular the changes to ddl.sgml and
Bruce Momjian wrote:
functionCURRENT_TIMESTAMP/ might not be the
transaction start time on other database systems.
For this reason, and for completeness,
functiontransaction_timestamp/ is provided.
Well, transaction_timestamp() is even more unlikely to be the
transaction start
Bruce Momjian wrote:
Peter Eisentraut wrote:
The most common complaint that I recall is that current_timestamp
returns the transaction timestamp rather than the statement timestamp,
which is what many expect. How does your patch address that?
No, we believe the standard requires it.
My
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
currently-useful information is intertwined with the reference to the
old behavior. If you can't be bothered to rewrite to preserve all of
the information, then don't remove the text.
I am working on Neils suggestion. I don't
Neil Conway wrote:
Bruce Momjian wrote:
functionCURRENT_TIMESTAMP/ might not be the
transaction start time on other database systems.
For this reason, and for completeness,
functiontransaction_timestamp/ is provided.
Well, transaction_timestamp() is even more unlikely
Neil Conway wrote:
Bruce Momjian wrote:
Peter Eisentraut wrote:
The most common complaint that I recall is that current_timestamp
returns the transaction timestamp rather than the statement timestamp,
which is what many expect. How does your patch address that?
No, we believe the
Neil Conway [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
One trick is that these should be the same:
test= SELECT statement_timestamp(), transaction_timestamp();
Should they be?
ISTM that the most useful definition of statement_timestamp is really
time of arrival of the latest interactive
Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
One trick is that these should be the same:
test= SELECT statement_timestamp(), transaction_timestamp();
Should they be?
ISTM that the most useful definition of statement_timestamp is really
time of arrival
I have made the modifications you suggested. Any others?
---
Neil Conway wrote:
[ Sorry for the two copies, Bruce: I forgot to CC the list previously ]
On Mon, 2006-03-20 at 13:57 -0500, Bruce Momjian wrote:
The
This is going to need a significant safety review.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
Is this patch moving toward competion?
---
Magnus Hagander wrote:
I just realised this mail didn't go through. Probably because it was too
large for -hackers. So: repost to -patches. Sorry about that. If it's a
17 matches
Mail list logo
