Re: help: now() + N is now failing! - Mailing list pgsql-novice

Stephan Szabo wrote:

>I don't mind an explicit conversion as much because at least you know
>that you're getting it.  Implicit conversions mean that a user has no
>reason to know (apart from name in this case) that the query should fail
>if you put 'T' in the column whereas a query like textcol::date is a
>pretty big hint.
>
Whatever... I have my reservations regarding how much of a hit this
really is (I mean a person who tries to compare a text column to a date,
and expects it to just magically always work, hardly deserves to be
expected to see anything behind that '::date' thing other then a weird
syntax construct :-)

But, as I said, I don't really have an opinion on this one - whether
parsing a text string into a date should be called a 'cast' or not...

My point is that if you do call certain type conversions 'a cast', and
you do allow implicit conversions in *some* cases (e.g. select * from
table where textcol < 3),
then it is actually *more* confusing to the user when you "hand-pick"
some of the type combinations and disallow those conversions, then it
would be, if you just had some simple (and commonly accepted) rule -
like allow any unambigous single-step conversions for example...
Or, for that matter - just never do any implicit conversions at all -
this would not be, of course something I'd like to happen :-), but, at
least, it would not make me wonder 'is this  going to work or not' every
time I type something into psql...

>You don't have to do one for every combination of types, only one for the
>reasonable ends of casting chains that make sense.
>
>
Yeah... but they are not always "chains" per se - they could be trees,
they could even have loops...
I guess, I could inspect all those graphs, decide what operators I want
defined, then make sure that they are not already defined in postgres,
then create all of those...
This begs the question though - why have *any* predefined operators at
all - if you did not have any, this task would actually be easier,
because, at least, I would not have to check my 'wish-list' of operators
against what's already defined in pg :-)

>The problem with downcasts is that the source type doesn't (always/often)
>give you reasonable values in the destination type. int8->int2 for
>example is probably unspecified behavior in C (for the signed type) for
>almost all values in int8.  You can call that short function with your
>long long, but the value you get in isn't likely to be what you expect in
>most cases.
>
Ok. No disagreement here... "C" gives you a warning in such case... and
postgres could do the same, or it could even refuse to do this
completely - fine with me.
*But* if there is an explicitly defined conversion function (like
date(timestamp) in our case), that *does* work for all the values
(granted, that you don't know if it actually does, but, the point being
- if it is defined explicitly, you should be able to assume that) - if
such a function is defined, it can safely be used for a type conversion.

Once again, if you want to argue against *any* implicit type conversion
*ever* - that would be a different thing.

But the way it is now, just seems very confusing, because *sometimes* it
does work, and sometimes it doesn't, and I really fail to see any
difference at all -
why, for example
select * from mytable where timestampcol < 3
.. works, but
select * from mytable where timestampcol + 1 < 4
does *not*?

Both queries make equally little sense... :-)

This seems to be a bug *whichever* way you look at it - either you
should make the first one fail, or you should make both of them work as
expected. 7.2 seems to be much closer to the latter - since it has a
date(int) conversion, and it allows timestamp + int... so, the only
thing missing is timestamp(int)...
And 7.3 seems to be actually *worse* in this respect - it is as much (if
not more) confusing, *and* some of the stuff one used to be able to do
in 7.2 is not longer possible :-(



>
>
>>>Effectively we have a Date(Timestamp) explicit
>>>constructor.
>>>
>>>
>>>
>>Ok, that beats your previous point, right? :-)
>>I mean, in C++ it is enough to have a constructor like that defined,
>>even if timestamp is not not a subclass of date, it can still be
>>implicitly converted, as long as the constructor is defined.... :-)
>>
>>
>
>No. I meant explicit in the C++ meaning, the constructor is not considered
>for implicit conversions but is available to be called explicitly like
>Date(timestampval).
>
>
Right... but "in C++ meaning" having such a constructor is enough to
have the parameter be implicitly  converted when necessary - so that
timestamp doesn't need to be a subclass of date - just having a
Date(Timestamp) thing is enough.

Dima