Re:

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Dave Page <dpage(at)vale-housing(dot)co(dot)uk>, Oliver Elphick <olly(at)lfix(dot)co(dot)uk>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re:
Date: 2002-09-13 22:37:16
Message-ID: Pine.LNX.4.44.0209132304280.1307-100000@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane writes:

> Shall we abandon all that work and go back to "any available cast can be
> applied implicitly"?
>
> My vote is "tough, time to fix your SQL code".

That would be a OK if the current behavior conformed to the SQL standard,
which it doesn't. The standard says that all numerical types are mutually
assignable, which in my mind translates directly as implicitly castable.
Additionally, your stance breaks the following SQL compatible and probably
quite common code:

create table test ( a int extract(year from current_date) );

We aren't abandoning "all that work". Plenty of casts should not be
implicit because they are structurally guaranteed to lose information. But
for casts between numerical types it depends on the content at run time.
Therefore the SQL standard says that the check needs to be at run time.
We do that already, so I don't see a reason to be more strict here.

--
Peter Eisentraut peter_e(at)gmx(dot)net

In response to

  • Re: at 2002-09-13 04:46:00 from Tom Lane

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2002-09-13 22:37:28 Inconsistent casts
Previous Message scott.marlowe 2002-09-13 21:55:35 Physical sites handling large data