Ken Johanson <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> These examples miss the point, because they'd give the same answer
>> whether you think the values are text or integer. ...
> Agreed, so should we disallow 7 > '08'?
Maybe, but the usability ramifications would be enormous --- you'd
al
Tom Lane wrote:
Ken Johanson <[EMAIL PROTECTED]> writes:
select 5<'6' -> true
select 5>'6' -> false
select 15<'60' -> true
select 15>'60' -> false
These examples miss the point, because they'd give the same answer
whether you think the values are text or integer. Consider instead
these cases:
Ken Johanson <[EMAIL PROTECTED]> writes:
> select 5<'6' -> true
> select 5>'6' -> false
> select 15<'60' -> true
> select 15>'60' -> false
These examples miss the point, because they'd give the same answer
whether you think the values are text or integer. Consider instead
these cases:
regression
Michael Glaesemann wrote:
On Feb 15, 2008, at 18:11 , Ken Johanson wrote:
Tom, is it accurate to assume that newer PG versions will further
tighten type-strictness (say, '2008-01-01' presently being comparable
to a datetime)? Also, do you know of any other vendors that are
heading in this di
Michael Glaesemann <[EMAIL PROTECTED]> writes:
> test=# select '2008-02-15' > CURRENT_DATE;
> Here, we're comparing against a date type, so Postgres treats
> '2008-02-15' as a date.
It might be worth pointing out that this is not magic,
but an application of the general rule mentioned at step 2
On Feb 15, 2008, at 18:11 , Ken Johanson wrote:
Tom, is it accurate to assume that newer PG versions will further
tighten type-strictness (say, '2008-01-01' presently being
comparable to a datetime)? Also, do you know of any other vendors
that are heading in this direction (removing by def
Tom Lane wrote:
It's possible to special-case any particular function you really feel
you need this behavior for. We did special-case || (the string
concatenation operator), and there was some discussion of also putting
in a built-in special case for LIKE, but we desisted from sliding any
furth
Jeff Davis wrote:
If postgresql were to revert to 8.2 implicit casting behavior, would
that actually improve compatibility with other DBMSs? Every DBMS
probably has it's own rules for implicit casting, different from every
other DBMS.
So are you sure it wouldn't just introduce more compatibility
Jeff Davis <[EMAIL PROTECTED]> writes:
> Are you saying we make special cases for all of the "obvious" functions,
> and they should behave differently from user-defined functions?
It's possible to special-case any particular function you really feel
you need this behavior for. We did special-case
On Thu, 2008-02-14 at 15:55 -0700, Ken Johanson wrote:
> Granted, some of the other databases have bugs in their CAST
> implementations (see http://bugs.mysql.com/bug.php?id=34562 &
> http://bugs.mysql.com/bug.php?id=34564) bugs which makes writing PG
> 8.3 portable code arduous or impossible
Ken Johanson <[EMAIL PROTECTED]> 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
11 matches
Mail list logo
