From: | "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu> |
---|---|
To: | sferac(at)bo(dot)nettuno(dot)it |
Cc: | Brett McCormick <brett(at)work(dot)chicken(dot)org>, pgsql-hackers(at)hub(dot)org |
Subject: | Re: [HACKERS] casting & type comments |
Date: | 1998-03-16 15:31:21 |
Message-ID: | 350D45C9.FFD3B9EE@alumni.caltech.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> I agree with you.
> Many databases as SOLID and MySQL don't have CAST statement because
> they don't need it.
They would need it if they were SQL92 conformant :)
> Unfortunately we need a CAST statement to convert data from one to
> another type but it is incomplete, seems that CAST can translate only
> a few types like:
> int to float
> float to int
> int to text
> float to text
>
> We can't CAST a char to a varchar, for example.
> It would be interesting al least to have a list of possible
> conversions.
The only thing lacking is for someone to go through and implement more
of the conversion functions. In conjunction with the improvements I
would like to do for automatic type conversion in the parser, this would
give us a more complete "transparent" conversion capability. CAST uses
the same underlying functions, but allows you to force the resultant
type, overriding any automatic conversion.
I tried selecting a list of all possible conversions, and narrowed it
down to 218 entries. But most are not actual straight conversions...
select proname, prorettype, proargtypes
from pg_proc
where pronargs = 1
and proname not like '%in'
and proname not like '%out'
- Tom
From | Date | Subject | |
---|---|---|---|
Next Message | The Hermit Hacker | 1998-03-16 15:35:43 | First mega-patch... |
Previous Message | Bruce Momjian | 1998-03-16 15:17:42 | Re: [HACKERS] DEC Alpha initdb partial fix |