| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Andy Balholm <andy(at)balholm(dot)com> |
| Cc: | Postgres-Bugs <pgsql-bugs(at)postgresql(dot)org>, craig(at)postnewspapers(dot)com(dot)au, farid(at)zidsoft(dot)com, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
| Subject: | Re: BUG #5490: INSERT doesn't force cast from text to timestamp |
| Date: | 2010-06-07 14:52:45 |
| Message-ID: | AANLkTinqaHuskUhj5blI3ngHUXIm74iTrmerIh2CXAdm@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Mon, Jun 7, 2010 at 10:30 AM, Andy Balholm <andy(at)balholm(dot)com> wrote:
> Craig Ringer wrote:
>> showing that your issue isn't actually with DISTINCT at all, but with Pg's unwillingness to *implicitly* cast a value of explict text type to another type.
>
> Is there a way to make values of "undefined" type pass through the SELECT DISTINCT filter (getting checked for uniqueness) but remain "undefined" if all the values supplied for the column are "undefined"? I don't know if the internal design of SELECT DISTINCT and the type system would allow for this, but if it would, it would take care of Farid's problem without introducing implicit type casts.
The issue isn't what's technically possible, but what's least likely
to lead to surprising behavior. This whole thread is basically about
whether implicit casts to and from text are a good idea or not. The
OP obviously thinks they are, and everyone else (whether they agree
with the behavior or not) is trying to explain the reasons why we
don't have them.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2010-06-07 14:53:17 | Re: BUG #5490: INSERT doesn't force cast from text to timestamp |
| Previous Message | Robert Haas | 2010-06-07 14:49:29 | Re: Invalid YAML output from EXPLAIN |