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?
