From: | Thomas Lockhart <lockhart(at)fourpalms(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Simeó Reig <simeo(at)incofisa(dot)com>, pgsql-general(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: CURRENT_TIME |
Date: | 2002-11-07 06:50:00 |
Message-ID: | 3DCA0D18.7020102@fourpalms.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
...
> In the long run, seems like it would be a good idea for type TIME
> WITHOUT TIME ZONE's input converter to accept and ignore a timezone
> field, just as type TIMESTAMP WITHOUT TIME ZONE does:
...
> Thomas, what do you think --- was this behavior deliberate or an
> oversight?
The behavior was deliberate, but predates the implementation of
TIMESTAMP WITHOUT TIME ZONE. The time zone is already ignored when
converting directly from TIME WITH TIME ZONE to TIME WITHOUT TIME ZONE:
lockhart=# select cast(time with time zone '2002-11-06
22:25:57.796141-05' as time);
time
-----------------
22:25:57.796141
and one could claim that this should be allowed from string constants too:
thomas=# select cast('2002-11-06 22:25:57.796141-05' as time);
time
-----------------
22:25:57.796141
Patch included to allow this latter case...
- Thomas
Attachment | Content-Type | Size |
---|---|---|
date.c.patch | text/plain | 1.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Huub | 2002-11-07 06:57:55 | primary key question |
Previous Message | Lee Tuck | 2002-11-07 04:37:37 | jdbc problem |
From | Date | Subject | |
---|---|---|---|
Next Message | Achilleus Mantzios | 2002-11-07 07:33:21 | Re: [SQL] Problem: Referential Integrity Constraints lost |
Previous Message | Billy G. Allie | 2002-11-07 06:48:20 | Re: [HACKERS] PostgreSQL supported platform report and a patch. |