Thread: casting & type comments
What do you all think about the fact that cast(anytype as varchar) results in a call to a procedure that is not creatable with 'create function'? Perhaps we should re-think our casting implementation, maybe one that isn't based on just rewriting itself into a function call :) If I wanted to call a function, I would :) I can, however, do a create function with a different name, then update that to varchar. the reason I can't, of course, is because the grammar expects varchar(number), not varchar(argument types).. there was probably a much better way of saying all that :)
> What do you all think about the fact that cast(anytype as varchar) > results in a call to a procedure that is not creatable with 'create > function'? Not too nice... > Perhaps we should re-think our casting implementation, > maybe one that isn't based on just rewriting itself into a function > call :) If I wanted to call a function, I would :) But, this is the real strength of Postgres, everything is treated uniformly and everything can be extended by defining functions. To hardcode certain types would be to lose the one of the most creative and desireable aspects of the system. > I can, however, do a create function with a different name, then > update that to varchar. the reason I can't, of course, is because the > grammar expects varchar(number), not varchar(argument types).. Perhaps the grammar could be fixed to allow this? -dg David Gould dg@illustra.com 510.628.3783 or 510.305.9468 Informix Software (No, really) 300 Lakeside Drive Oakland, CA 94612 - I realize now that irony has no place in business communications.
On Fri, 13 March 1998, at 15:19:24, David Gould wrote: > > What do you all think about the fact that cast(anytype as varchar) > > results in a call to a procedure that is not creatable with 'create > > function'? > > Not too nice... > > > Perhaps we should re-think our casting implementation, > > maybe one that isn't based on just rewriting itself into a function > > call :) If I wanted to call a function, I would :) > > But, this is the real strength of Postgres, everything is treated uniformly > and everything can be extended by defining functions. To hardcode certain > types would be to lose the one of the most creative and desireable aspects > of the system. I'm certainly not saying that this aspect of the postgres system should be changed, but rather a different way of mapping casts to functions, so we don't run into problems like this, and perhaps a fall-back to a straight string cast (i.e. call the destination types input function on the return value of the source types output function).. One downside to all this is if I already have a function called whatever, and suddenly someone wants to add a type called whatever, that function would be used for casting when it really shouldn't, and could have unexpected results.. --brett > > > I can, however, do a create function with a different name, then > > update that to varchar. the reason I can't, of course, is because the > > grammar expects varchar(number), not varchar(argument types).. > > Perhaps the grammar could be fixed to allow this? > > -dg > > David Gould dg@illustra.com 510.628.3783 or 510.305.9468 > Informix Software (No, really) 300 Lakeside Drive Oakland, CA 94612 > - I realize now that irony has no place in business communications.
> > > What do you all think about the fact that cast(anytype as varchar)
> > > results in a call to a procedure that is not creatable with
> > > 'create function'?
> > > Perhaps we should re-think our casting implementation,
> > > maybe one that isn't based on just rewriting itself into a
> > > function call :) If I wanted to call a function, I would :)
No you wouldn't. There are too many functions with wildly varying names
to keep all of them in your head.
> > But, this is the real strength of Postgres, everything is treated uniformly
> > and everything can be extended by defining functions. To hardcode certain
> > types would be to lose the one of the most creative and desireable aspects
> > of the system.
>
> I'm certainly not saying that this aspect of the postgres system
> should be changed, but rather a different way of mapping casts to
> functions, so we don't run into problems like this, and perhaps a
> fall-back to a straight string cast (i.e. call the destination types
> input function on the return value of the source types output
> function)..
That already happens if you do not specify an explicit cast.
> One downside to all this is if I already have a function called
> whatever, and suddenly someone wants to add a type called whatever,
> that function would be used for casting when it really shouldn't, and
> could have unexpected results..
Not likely. Postgres does match up the types correctly, since it allows
function overloading. So the only problem comes if you have a function
name with the same input arguments, and the function name happens to be
the same name as the new type.
> > > I can, however, do a create function with a different name, then
> > > update that to varchar. the reason I can't, of course, is because
> > > the grammar expects varchar(number), not varchar(argument types)..
> >
> > Perhaps the grammar could be fixed to allow this?
I'm planning on working on the type conversion stuff. Not certain yet
how to handle varchar; SQL92 has this ad-hoc type syntax for some types
which makes it difficult to generalize. We might have to have a few
special cases to handle the grungy SQL92 stuff, and try to leave the
rest of it generic.
Other types, like numeric and decimal, have the same problem with extra
parameters associated with the type.
- Tom
On Sat, 14 March 1998, at 02:59:36, Thomas G. Lockhart wrote: > No you wouldn't. There are too many functions with wildly varying names > to keep all of them in your head. I like to use IP numbers, too :) > > I'm certainly not saying that this aspect of the postgres system > > should be changed, but rather a different way of mapping casts to > > functions, so we don't run into problems like this, and perhaps a > > fall-back to a straight string cast (i.e. call the destination types > > input function on the return value of the source types output > > function).. > > That already happens if you do not specify an explicit cast. My mistake, is this new in 6.3? > > > One downside to all this is if I already have a function called > > whatever, and suddenly someone wants to add a type called whatever, > > that function would be used for casting when it really shouldn't, and > > could have unexpected results.. > > Not likely. Postgres does match up the types correctly, since it allows > function overloading. So the only problem comes if you have a function > name with the same input arguments, and the function name happens to be > the same name as the new type. That's the situation I was citing, sorry for not being clear. > I'm planning on working on the type conversion stuff. Not certain yet > how to handle varchar; SQL92 has this ad-hoc type syntax for some types > which makes it difficult to generalize. We might have to have a few > special cases to handle the grungy SQL92 stuff, and try to leave the > rest of it generic. > > Other types, like numeric and decimal, have the same problem with extra > parameters associated with the type. Speaking of which, how is the atttypmod passed?
> > I'm planning on working on the type conversion stuff. Not certain yet > > how to handle varchar; SQL92 has this ad-hoc type syntax for some types > > which makes it difficult to generalize. We might have to have a few > > special cases to handle the grungy SQL92 stuff, and try to leave the > > rest of it generic. > > > > Other types, like numeric and decimal, have the same problem with extra > > parameters associated with the type. > > Speaking of which, how is the atttypmod passed? It is used internally, but not passed to functions. Not sure how to address that. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
Sorry, I meant at table creation time.. What are the implications of atttypmod in any case? it is just a general purpose number to attach to attributes (for precision etc), correct? On Fri, 13 March 1998, at 22:55:36, Bruce Momjian wrote: > It is used internally, but not passed to functions. Not sure how to > address that. > > -- > Bruce Momjian | 830 Blythe Avenue > maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 > + If your life is a hard drive, | (610) 353-9879(w) > + Christ can be your backup. | (610) 853-3000(h)
> > > Sorry, I meant at table creation time.. What are the implications of > atttypmod in any case? it is just a general purpose number to attach > to attributes (for precision etc), correct? > It is passed to all input and output functions for each type as the third argument. You can see its use in char() and varchar(). -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
On Thu, 12 Mar 1998, Brett McCormick wrote:
>
> What do you all think about the fact that cast(anytype as varchar)
> results in a call to a procedure that is not creatable with 'create
> function'? Perhaps we should re-think our casting implementation,
> maybe one that isn't based on just rewriting itself into a function
> call :) If I wanted to call a function, I would :)
>
> I can, however, do a create function with a different name, then
> update that to varchar. the reason I can't, of course, is because the
> grammar expects varchar(number), not varchar(argument types)..
>
> there was probably a much better way of saying all that :)
>
I agree with you.
Many databases as SOLID and MySQL don't have CAST statement because they
don't need it.
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.
Ciao, Jose'
> 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