From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Ken Johanson <pg-user(at)kensystem(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Strict-typing benefits/costs |
Date: | 2008-02-14 23:34:01 |
Message-ID: | 20844.1203032041@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Ken Johanson <pg-user(at)kensystem(dot)com> writes:
> For case 1, regarding type safety: we know use of LIKE (and SUBSTR)
> requires *implicit or explicit* conversion to a text type. Why require
> that explicitly?
Because it's way too easy to burn yourself with implicit conversions.
Cases comparable to the one mentioned (current_date < 2017-11-17
silently doing something very different than the user expected) have
been cropping up every month or two for *years* --- try trolling the
PG list archives for awhile for examples. After you've wasted a day or
three chasing a problem like that, or pehaps had your app fail in the
field because of a problem like that, you'll realize that having to
write a few explicit casts is a small price to pay for not having such
booby-traps in the system.
As for the lack of a compatibility switch, we would probably have
provided one if we could do so reasonably; but a large part of the
change consisted of altering the initial contents of pg_cast and some
other system catalogs. There isn't any good way to flip that on and
off.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Stephan Szabo | 2008-02-14 23:35:28 | Re: SELECT CAST(123 AS char) -> 1 |
Previous Message | Ken Johanson | 2008-02-14 22:55:31 | Strict-typing benefits/costs |