> > > 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