Hi!
Recently, we switched from Pg 8.3 to Pg 9.1, using Pg9's pg_upgrade to
migrate our cluster. The cluster itself is running on a Debian 6 machine
with timezone Europe/Berlin, which means UTC+02 currently.
Under Pg 8.3, we used the timestamp
0001-01-01 00:00:00+01
as an easy-to-remember marker
On pią, maj 10, 2013 at 10:34:02 +0200, Karsten Düsterloh wrote:
> Under Pg 8.3, we used the timestamp
> 0001-01-01 00:00:00+01
> as an easy-to-remember marker for 'dunno, but predates any usual
> business dates' for fields of type timestamp with time zone.
Why didn't you use "-infinity" for thi
hubert depesz lubaczewski wrote:
>> Under Pg 8.3, we used the timestamp
>> 0001-01-01 00:00:00+01
>> as an easy-to-remember marker for 'dunno, but predates any usual
>> business dates' for fields of type timestamp with time zone.
>
> Why didn't you use "-infinity" for this?
Back when that value
Karsten Düsterloh wrote
> hubert depesz lubaczewski wrote:
> > ZoneEurope/Berlin 0:53:28 - LMT 1893 Apr
> The question remains, though, where this special value comes from ?
That was probably the local time at Berlin, with 12:00 the moment when the
sun was highest. With the advent
=?ISO-8859-1?Q?Karsten_D=FCsterloh?= writes:
> Under Pg 8.3, we used the timestamp
> 0001-01-01 00:00:00+01
> as an easy-to-remember marker for 'dunno, but predates any usual
> business dates' for fields of type timestamp with time zone.
Have you considered using '-infinity'?
> With Pg 9.1, th
Patryk Kordylewski writes:
> SET lc_numeric TO 'de_DE.UTF-8';
> SET
> SELECT
>TO_CHAR(123456789.123, 'FM99G999G999G999G999G999G999D000'),
>TO_NUMBER(TO_CHAR(123456789.123, 'FM99G999G999G999G999G999G999D000'),
> 'FM99G999G999G999G999G999G999D000');
> to_char | to_number
> --
Tom Lane wrote on 10.05.2013 17:49:
I looked into this, and find that the reason it misbehaves is that
NUM_numpart_from_char() will treat a '.' as being a decimal point
*without any regard to locale considerations*. So even if we have
a locale-dependent format string and a locale that says '.' i
That was quick. Applied the 91715e82932665 commit directly against the 9.2.4
pgdg source, fix works great. Test data and the original breaking production
queries run fine for me. Thank you very much!
-joel
On May 9, 2013, at 6:19 PM, Tom Lane wrote:
> jrol...@rjobrien.com writes:
>> We've
On 10-05-2013 13:09, Thomas Kellerer wrote:
> Tom Lane wrote on 10.05.2013 17:49:
>> I looked into this, and find that the reason it misbehaves is that
>> NUM_numpart_from_char() will treat a '.' as being a decimal point
>> *without any regard to locale considerations*. So even if we have
>> a loc
