X-Original-To: pgsql-patches-postgresql.org@postgresql.org
Received: from localhost (mx1.hub.org [200.46.208.251])
	by postgresql.org (Postfix) with ESMTP id 0A9EA9FB380
	for <pgsql-patches-postgresql.org@postgresql.org>;
	Tue,  1 Aug 2006 04:23:30 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024)
	with ESMTP id 85707-01-10 for
	<pgsql-patches-postgresql.org@postgresql.org>;
	Tue,  1 Aug 2006 04:23:09 -0300 (ADT)
X-Greylist: domain auto-whitelisted by SQLgrey-
Received: from py-out-1112.google.com (py-out-1112.google.com
 [64.233.166.177])
	by postgresql.org (Postfix) with ESMTP id 083569FB359
	for <pgsql-patches@postgresql.org>;
	Tue,  1 Aug 2006 04:15:57 -0300 (ADT)
Received: by py-out-1112.google.com with SMTP id b36so817693pyb
	for <pgsql-patches@postgresql.org>;
	Tue, 01 Aug 2006 00:15:52 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references;
	b=QXIwkfjZVp9OLfRjXcinKuTwHtESi4bgRUozciPLYny2t+JUtJbRMW9YefEYWe7OsFF+Jvna9dziJhza06tyxNQ104a9HWnTRLvX8/FBxLDQSHUWOm1Qs/C3M1eUDbg1b14djcfliWm09CDLSF+x6FdoSL2jb1xIve3/aWgjsnM=
Received: by 10.65.59.20 with SMTP id m20mr4764818qbk;
	Tue, 01 Aug 2006 00:15:52 -0700 (PDT)
Received: by 10.35.123.13 with HTTP; Tue, 1 Aug 2006 00:15:52 -0700 (PDT)
Message-ID: <7be3f35d0608010015j750f0b5axacd9753ec79bd46e@mail.gmail.com>
Date: Tue, 1 Aug 2006 09:15:52 +0200
From: "Harald Armin Massa" <haraldarminmassa@gmail.com>
To: "Joshua D. Drake" <jd@commandprompt.com>
Subject: Re: [HACKERS] 8.2 features?
Cc: "Patches (PostgreSQL)" <pgsql-patches@postgresql.org>
In-Reply-To: <44CE7A45.70400@commandprompt.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_67918_24343317.1154416552597"
References: <200607281947.k6SJlOI02533@momjian.us>
	<44CA76A9.8070101@joeconway.com> <44CB051D.6090609@joeconway.com>
	<21320.1154222840@sss.pgh.pa.us> <26226.1154279741@sss.pgh.pa.us>
	<44CE529F.2070701@joeconway.com> <9049.1154373020@sss.pgh.pa.us>
	<20060731201943.GF20962@alvh.no-ip.org>
	<20060731204456.GA67809@winnie.fuhr.org>
	<44CE7A45.70400@commandprompt.com>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=0.15 tagged_above=0 required=5 tests=AWL,
	DNS_FROM_RFC_ABUSE, HTML_MESSAGE, SPF_PASS
X-Spam-Level: 
X-Archive-Number: 200608/5
X-Sequence-Number: 20521

------=_Part_67918_24343317.1154416552597
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Joshua,

> So now it's MySQL users' turn to say, "Sure, but speed isn't
> > everything...." :-)
> "Sure, but speed isn't everything... We can accept 02/31/2006 as a valid
> date. Let's see PostgreSQL do that!"
>

I got the joke :)

But: it is still a problem when converting. As accepting 2006-02-31 as a
valid date would require brainwashing at least the entire core team, we
should find a "recommended path of date migration from different universes"=
.

My idea would be to:

a) declare date fields as text
b) load the dump of the other db
c) add another column for the date fields, type timestampe (w/wo tz)
d) try to update the column of c) with the converted field from a)
e) replace the failing ones manually

is this really best practice? especially finding the invalid ones would be
challenging :(
idea: sort after the textual date fields; look at hot spots (0000-00-00,
xxxx-02-31)

Are there better ideas? shall we document the best practice somewhere?

Harald
--=20
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Reinsburgstra=DFe 202b
70197 Stuttgart
0173/9409607
-
Let's set so double the killer delete select all.

------=_Part_67918_24343317.1154416552597
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Joshua,<br><br><div><blockquote class=3D"gmail_quote" style=3D"border-left:=
 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex=
;">&gt; So now it's MySQL users' turn to say, &quot;Sure, but speed isn't<b=
r>
&gt; everything....&quot; :-)<br>&quot;Sure, but speed isn't everything... =
We can accept 02/31/2006 as a valid<br>date. Let's see PostgreSQL do that!&=
quot;<br></blockquote></div><br>I got the joke :)<br><br>But: it is still a=
 problem when converting. As accepting 2006-02-31 as a valid date would req=
uire brainwashing at least the entire core team, we should find a &quot;rec=
ommended path of date migration from different universes&quot;.
<br><br>My idea would be to:<br><br>a) declare date fields as text<br>b) lo=
ad the dump of the other db<br>c) add another column for the date fields, t=
ype timestampe (w/wo tz)<br>d) try to update the column of c) with the conv=
erted field from a)
<br>e) replace the failing ones manually<br><br>is this really best practic=
e? especially finding the invalid ones would be challenging :(<br>idea: sor=
t after the textual date fields; look at hot spots (0000-00-00, xxxx-02-31)
<br><br>Are there better ideas? shall we document the best practice somewhe=
re?<br><br>Harald<br>-- <br>GHUM Harald Massa<br>persuadere et programmare<=
br>Harald Armin Massa<br>Reinsburgstra=DFe 202b<br>70197 Stuttgart<br>0173/=
9409607
<br>-<br>Let's set so double the killer delete select all.

------=_Part_67918_24343317.1154416552597--