On 1 March 2011 06:39, silly sad <sad@bestmx.ru> wrote:
> On 02/28/11 22:58, damien clochard wrote:
>> Le 26/02/2011 22:39, Josh Berkus a écrit :
>>>
>>>> Well, it's with the minutes of the 2007 developer meeting ... *if*
>>>> anyone can find that on the wiki. Someday we need to fix wiki search.
>>>
>>> Aha found it, no thanks to wiki search, and no thanks to Spotlight either.
>>>
>>> So, my memory was wrong. Actually, they reported having a one-click
>>> install as the #1 issue, not the #3 issue:
>>>
>>> 1. Easy Install
>>>
>>> 2. Simple, low-overhead replication
>>>
>>> 3. Upgrade-in-place
>>>
>>> 4. Administration & monitoring
>>>
>>> 5. Driver quality/maintenance
>>>
>>> ... it's really nice the number of the above issues we've knocked out
>>> since 2007.
>>>
>>
>> yes... it would be interesting to know what are the 5 next challenges :)
>
> 1. To get rid of nasty CSTRING type
> 2. To get rid of the difference between TEXT and BYTEA (and then get rid
> of the BYTEA)
> 3. To make TIMESTAMPTZ useful by introducing proper type cast
> TIMESTAMPTZ to TIMESTAMP
> 4. Introduce a pair of preferences (server_timezone, client_timezone)
> instead of a single pref (timezone) (and use their values similar as
> (client_encoding, server_encoding) are used)
> 5. N/A
>
> the Postrgesql is too good for me to compose 5th challenge.
> but these four are too disturbing and irrational.
>
> example
>
> SELECT 'epoch'::TIMESTAMP = 'epoch'::TIMESTAMPTZ::TIMESTAMP;
>
> OOPS! we have TWO DIFFERENT EPOCHS!!!
No, you have one which doesn't apply the timezone difference, and one
which does. So if you're UTC+1, you end up with:
'1970-01-01 00:00:00' = '1970-01-01 01:00:00' -- false
When you cast this timestamp with timezone to a normal timestamp, it
retains the time, but not the timezone.
--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935