From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Josh Berkus" <josh(at)agliodbs(dot)com> |
Cc: | pgsql-sql(at)postgresql(dot)org |
Subject: | Re: Timestamp operator error |
Date: | 2002-02-26 04:47:35 |
Message-ID: | 27308.1014698855@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
"Josh Berkus" <josh(at)agliodbs(dot)com> writes:
> Any suggestions on an emergency fix for my (production) database?
Emergency fix? This operator didn't behave reasonably in 7.1 either
(at least not by my definition of reasonable). What exactly would
you have us do?
>> I suspect this is good ammunition for the argument I've made from
>> time to time that we have too many implicit conversions, not too few.
> Yes, definitely. Frankly, I'd prefer a large reduction in implicit
> conversions; I just got into trouble with the difference between
> current_timestamp and current_date that I would have caught much
> earlier if Postgres had disallowed the implicit conversion.
Yah. Offhand I'd argue that no information-discarding conversion
should be implicitly invokable. date->timestamp is fine;
timestamp->date should require an explicit cast. I've already proposed
that we add a flag to pg_proc to distinguish implicit from explicit
conversion operations, and no one complained. But we have not yet
begun to argue about exactly which conversions should be allowed
implicitly...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2002-02-26 05:03:39 | Re: Timestamp operator error |
Previous Message | Josh Berkus | 2002-02-26 04:34:36 | Re: Timestamp operator error |