Re: New thoughts about indexing cross-type comparisons

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.
> 
> Comments?  Does this spur any better ideas?

I still think that this is a type inference problem and nothing else. The
problem with an expression like int2col = 42 is that the parser tries
directly to put a type on the constant 42 while it shouldn't. 42 is not a
int4 value, it's also not a int8 value. By introducing a type variables
and say that the 42 :: alpha and some constraint saying "Int alpha" then
then you after parsing look at all your type variables and try to assign
real types to them that is consistent (the type inference phase). Another 
way is to say that 42 :: int2 and then having some subtyping rules saying 
that int2 < int4 and int4 < int8 so the type system can insert coercions 
in order to make a concistent typing of the term.

Things to look at is Hindley-Miller type inference and subtyping.

What I'm afraid of is that there are more and more ad hock solutions added
to postgresql but no overall strategy. For example in 7.4 there are
polymorphism that is something that hindley miller type systems have
always been good at but I don't know exactly what pg uses and how it's
checking types. I'm not saying that there is anything wrong with
polymorphism as added. I don't know enough of it to say anything about it.

Another thing I don't understand is why '42' works but not 42. Is it the
case that you can always write '42' in places where pg expects an integer?  
That suggest to me that '42' is treated as something with an unknown type
(let's call it alpha), where the type is infered later on depending on how
it is used (alpha is assigned to int2 or something). Sounds very much like
what I talk about above. Why is not 42 treated in the same way? If someone
want 42 to be an integer to for example select a specific overloaded
function they would have to write 42::integer instead (or some defaulting 
could be added).

I feal bad to talk about the pg type system without knowing all details
about it. But I do know a little about type systems in general, so I still
want to share some thoughts. I wrote a similar message 6 months ago or
something. If you get a deja vu feeling you know why :-)

I wish I had lots of money so I could take 6 months off and just spend on
pg. Then I would start by writing down how the current type system works
and try to create a new nice type system that works without a lot of ad
hock solutions. Unfortunatly there is a reality where you have to pay 
the rent and so on... 

-- 
/Dennis