For the int2col op value I have this table for when the cast returns NULL
value 0
, = ,= int2col=null
,= in2col is not null
value 0
,= in2col is not null
=,,= int2col=null
Im not sure why pg allows me to do a int2col=null and returns nothing
so I am assuming that internally pg just resolves
On Tue, 16 Sep 2003, Tom Lane wrote:
This is not a 100% solution to our problems. I don't think we could use
it to solve the problem for int2 columns (int2col = 42) because it'd
be unsafe to promise that an int4-to-int2 cast could be inserted into
an expression without changing the behavior.
Dennis Bjorklund [EMAIL PROTECTED] writes:
I still think that this is a type inference problem and nothing else.
Well, perhaps ripping out the entire type resolution algorithm and
replacing it with something less ad-hoc is indeed the right long-term
answer. I don't have time to do that though.
On Wed, 17 Sep 2003, Tom Lane wrote:
Another thing to keep in mind is that it's not always the case that
assigning the right type to a literal constant would solve the problem.
We have the same issues with variables; for example, a join with
WHERE a.int8col = b.int4col may fail to take
Dennis Bjorklund [EMAIL PROTECTED] writes:
On Wed, 17 Sep 2003, Tom Lane wrote:
So I'm beginning to think that avoiding cross-type operators is not the
right route to a solution anyway. It may be better to leave the parser
alone and teach the planner how to switch to the alternate
Tom Lane wrote:
Dave Smith [EMAIL PROTECTED] writes:
My point was that it was inconstant behavour. What exactly are you
comparing with int2? To me the case without the cast should should throw
the same error as the statement with the cast.
select * from test where f=1981928928921;
Kevin Brown [EMAIL PROTECTED] writes:
Hmm...but what if the cast were to return NULL in the event that the cast
fails or cannot be done? Would that even be reasonable?
Yeah, I was wondering about that myself. I'd not want to try to use
such an idea in general, but if we find that int2 indexes
We've spent much effort trying to solve the int8col = 42 doesn't use
an index class of problems. AFAIR, all the recent tries have focused
on trying to get the parser to choose an index-compatible operator
initially. (In this example, that would mean promoting 42 to int8 so
that int8 = int8 would
If this is only dealing with constants, why not just explicitly add a
cast to the constant of the column type at the planner level. It would
solve this problem as well ...
create table test (f int2);
select * from test where f=cast('1981928928921' as int2);
ERROR: pg_atoi: error reading
Dave Smith [EMAIL PROTECTED] writes:
If this is only dealing with constants, why not just explicitly add a
cast to the constant of the column type at the planner level. It would
solve this problem as well ...
create table test (f int2);
select * from test where f=cast('1981928928921' as
My point was that it was inconstant behavour. What exactly are you
comparing with int2? To me the case without the cast should should throw
the same error as the statement with the cast.
Tom Lane wrote:
Dave Smith [EMAIL PROTECTED] writes:
If this is only dealing with constants, why not just
Dave Smith [EMAIL PROTECTED] writes:
My point was that it was inconstant behavour. What exactly are you
comparing with int2? To me the case without the cast should should throw
the same error as the statement with the cast.
select * from test where f=1981928928921;
I contend not. The
Tom Lane wrote:
Dave Smith [EMAIL PROTECTED] writes:
If this is only dealing with constants, why not just explicitly add a
cast to the constant of the column type at the planner level. It would
solve this problem as well ...
create table test (f int2);
select
13 matches
Mail list logo
