time_stamp type
in [PgSql]
|
Prev: introduction of WIP window function patch
Next: Solaris ident authentication using unix domainsockets
From: "Stephen R. van den Berg" on 5 Jul 2008 12:34 What's the deal with this type? Is it used internally? It's the only type that seems to have anything meaningfull in typdefaultbin and typdefault columns in pg_type. -- Sincerely, Stephen R. van den Berg. WARNING: Do not look into laser with remaining eye -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 6 Jul 2008 01:19
"Stephen R. van den Berg" <srb(a)cuci.nl> writes: > What's the deal with this type? It's a domain over timestamptz, as required by the SQL spec definition of the information_schema. postgres=# \dD information_schema.time_stamp List of domains Schema | Name | Type | Modifier | Check --------------------+------------+-----------------------------+----------------------------------------------------+------- information_schema | time_stamp | timestamp(2) with time zone | default ('now'::text)::timestamp(2) with time zone | (1 row) [ re-reads spec... ] Hm, actually the spec is self-contradictory here: SQL99 20.7 saith CREATE DOMAIN TIME_STAMP AS TIMESTAMP (2) DEFAULT CURRENT_TIMESTAMP(2); which appears to imply that TIME_STAMP is a domain over timestamp *without* time zone ... but that is contradicted by the specification that the default is CURRENT_TIMESTAMP, which yields a value *with* time zone. (LOCALTIMESTAMP is the function that should have been mentioned if they really meant without time zone.) [ pokes further... ] Hmm, last year's SQL200n draft saith CREATE DOMAIN TIME_STAMP AS TIMESTAMP(2) WITH TIME ZONE; with no mention of a default. I do wish these people could make up their minds. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |