From: | "David E(dot) Wheeler" <david(at)kineticode(dot)com> |
---|---|
To: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
Cc: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>, <pgsql-hackers(at)postgresql(dot)org>, "Scott Mohekey" <scott(dot)mohekey(at)telogis(dot)com> |
Subject: | Re: Timestamp to time_t |
Date: | 2009-09-15 20:16:38 |
Message-ID: | 57856C2B-4524-4FB2-9D1B-B06A4E8A0666@kineticode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sep 15, 2009, at 11:01 AM, Andrew Gierth wrote:
> If you want to store both a timestamp and an associated timezone you
> can do
> it right now, using a composite type or two columns, with the
> advantage that
> you get semantics that you can rely on.
How would a composite work in practice? Can you index it on the
timestamp? Or would you have to use two columns for that?
I could see a real advantage to a type that stored the TZ with which
it was created, with the ability to fetch it back out. Internally the
data could be stored just like it is with timestamptz, and by default,
perhaps, it would display in $PGTZ, but if $PGTZ was set to a value
like "original" or something, it should display the originals. Now
*that* would be really useful IMHO.
Best,
David
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2009-09-15 20:20:51 | Re: [BUGS] BUG #5053: domain constraints still leak |
Previous Message | David Fetter | 2009-09-15 19:49:27 | Re: WIP: generalized index constraints |