Skip to Main Content
  • Questions
  • Can we change default TIMESTAMP (6) precision per session or database?

Breadcrumb

Question and Answer

Tom Kyte

Thanks for the question, Duke.

Asked: March 24, 2008 - 12:13 pm UTC

Last updated: July 31, 2013 - 4:28 pm UTC

Version: 10.0.2

Viewed 10K+ times! This question is

You Asked

While trawling David Aldridge's site
http://oraclesponge.wordpress.com/2008/03/07/timestamps-old-fogeys-and-data-warehouses/
I wondered, but could not find in the documentation: Is there any way of changing the default precision of 6 for TIMESTAMP at a global or session level (instead of column at creation)?

Thanks!

and Tom said...

http://docs.oracle.com/cd/B19306_01/server.102/b14200/sql_elements001.htm#i53219

the default is six, much like the default for a number is (*,*) and the default for a char is 1 and a default for a varchar2 is "not defined"..

and the defaults are the default - constantly and consistently applied. You cannot change the default value used for them, you have to manually specify what you want if the default is not appropriate.

Rating

  (3 ratings)

Is this answer out of date? If it is, please let us know via a Comment

Comments

changing precision

Duke Ganote, March 26, 2008 - 5:47 am UTC

Timestamps are cumbersome to modify:

drop table t;

Table dropped.

create table t as select systimestamp ts from dual;

Table created.

alter table t modify ts timestamp (0);
alter table t modify ts timestamp (0)
*
ERROR at line 1:
ORA-01439: column to be modified must be empty to change datatype


alter table t modify ts timestamp (9);
alter table t modify ts timestamp (9)
*
ERROR at line 1:
ORA-01439: column to be modified must be empty to change datatype

Tom Kyte
March 26, 2008 - 9:02 am UTC

just like numbers and strings - only numbers and strings (varchar2 strings) can be made larger easily (not smaller)

timestamps are a fixed width datatype, changing the size would require rewriting the ENTIRE table (unless they are all null)


David Aldridge, March 26, 2008 - 7:48 pm UTC

>> ... changing the size would require rewriting the ENTIRE table (unless they are all null)

I still wish we had the option to override the "no non-null values" check though, and just take any pain associated with the required changes. I suppose that the major issues would be migrated rows, a locked table, a potentially high i/o load, data segment compression issues, and having to deal with indexes.

To not be able to for the sake of one non-null value out of fifty gazillion null values is a frustration. I'm not saying there isn't a way round it, or that it's particularly onerous, but there are cases when it would be a useful option.

Tom Kyte
March 27, 2008 - 10:31 am UTC

dbms_redefinition would do that and avoid the ... migrated rows, a locked table, a potentially
high i/o load, data segment compression issues, and having to deal with
indexes. ....

issues.

client machine timestamp

A reader, July 22, 2013 - 5:48 pm UTC

Hi Tom,
machine1 time;9:10 am(client)
machine2 time: 11:00 am(server)

When we connect from machine1(client) to machine2(server) the server time is displayed from systimestamp,current_timestamp and localtimestamp.
########
11:00
#########

How could I see the time of client machine that is
#####
9:10
#####


I think if we know client machine's time zone then we can find from below query.
###########
SELECT SYSTIMESTAMP AT TIME ZONE '+00:00' from dual;
###########
But can we get it dierctly
Is there any direct identifer something like client_timestamp ,so we can get client machine timestamp.

thanks
Tom Kyte
July 31, 2013 - 4:28 pm UTC

the client would have to have sent it over (and keep sending it over). The clients do not do this. Your client - your code in short - would have to do this.