pgsql/src backend/access/transam/xact.c backen ...
CVSROOT: /cvsroot
Module name: pgsql
Changes by: thomas@postgresql.org 01/09/28 04:09:14
Modified files:
src/backend/access/transam: xact.c
src/backend/parser: gram.y parse_coerce.c parse_expr.c
parse_target.c
src/backend/utils/adt: date.c datetime.c format_type.c
formatting.c nabstime.c timestamp.c
src/include/access: xact.h
src/include/catalog: catversion.h duplicate_oids pg_aggregate.h
pg_amop.h pg_amproc.h pg_opclass.h
pg_operator.h pg_proc.h pg_type.h
src/include/utils: builtins.h date.h datetime.h formatting.h
nabstime.h timestamp.h
Log message:
Measure the current transaction time to milliseconds.
Define a new function, GetCurrentTransactionStartTimeUsec() to get the time
to this precision.
Allow now() and timestamp 'now' to use this higher precision result so
we now have fractional seconds in this "constant".
Add timestamp without time zone type.
Move previous timestamp type to timestamp with time zone.
Accept another ISO variant for date/time values: yyyy-mm-ddThh:mm:ss
(note the "T" separating the day from hours information).
Remove 'current' from date/time types; convert to 'now' in input.
Separate time and timetz regression tests.
Separate timestamp and timestamptz regression test.
I'm seeing the following failure in the rules regress test:
$ diff expected/rules.out results
1338c1338
< shoelace_data | log_shoelace | CREATE RULE log_shoelace AS ON UPDATE TO shoelace_data WHERE (new.sl_avail <> old.sl_avail) DO INSERT INTO shoelace_log (sl_name, sl_avail, log_who, log_when) VALUES (new.sl_name, new.sl_avail, 'Al Bundy'::name, 'Thu Jan 01 00:00:00 1970'::"timestamp");
---
shoelace_data | log_shoelace | CREATE RULE log_shoelace AS ON UPDATE TO shoelace_data WHERE (new.sl_avail <> old.sl_avail) DO INSERT INTO shoelace_log (sl_name, sl_avail, log_who, log_when) VALUES (new.sl_name, new.sl_avail, 'Al Bundy'::name, "timestamp"('epoch'::text));
$
The actual result corresponds to the former output, and is indeed what
I would expect, given that text_timestamp() is (and should be)
non-cachable. Are you sure this expected file is correct?
I'm also seeing rather massive failures in horology, but this evidently
is because horology-no-DST-before-1970.out hasn't been updated ...
regards, tom lane
I'm seeing the following failure in the rules regress test:
...
The actual result corresponds to the former output, and is indeed what
I would expect, given that text_timestamp() is (and should be)
non-cachable. Are you sure this expected file is correct?
It was, when I had marked that function as cachable. I went through the
catalog one last time and changed it back (apparently).
I'm also seeing rather massive failures in horology, but this evidently
is because horology-no-DST-before-1970.out hasn't been updated ...
Right. I've got one failure in horology myself, since one test was
sensitive to DST and has a transition which apparently happened last
night!
Both should be fixed now. Or would be if cvs.postgresql.org was
responding to requests for ssh. I've enclosed a patch file to be
applied, if you would like to do the honors.
I don't have the right kind of box to be able to test horology for the
"pre1970 crowd" myself, so others will have to do it.
- Thomas
Attachments:
datetime.patchestext/plain; charset=us-ascii; name=datetime.patchesDownload+14-14
Thomas Lockhart <lockhart@fourpalms.org> writes:
Both should be fixed now. Or would be if cvs.postgresql.org was
responding to requests for ssh. I've enclosed a patch file to be
applied, if you would like to do the honors.
Done.
I don't have the right kind of box to be able to test horology for the
"pre1970 crowd" myself, so others will have to do it.
I updated horology-no-DST-before-1970.out. We still need someone
to submit updated result files for the solaris-1947 cases.
regards, tom lane