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

Thu, 12 Mar 1998 23:13:45 -0800 (PST)
Brett McCormick <brett@work.chicken.org>
casting & type comments
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'


Fri, 13 Mar 1998 17:57:33 +0000 (GMT)
sferac@bo.nettuno.it
Re: [HACKERS] 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'? 

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.


Fri, 13 Mar 1998 15:19:24 -0800 (PST)
dg@illustra.com (David Gould)
Re: [HACKERS] casting & type comments
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.

Fri, 13 Mar 1998 15:41:29 -0800 (PST)
Brett McCormick <brett@work.chicken.org>
Re: [HACKERS] 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 :)

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

Sat, 14 Mar 1998 02:59:36 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] casting & type comments
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?

Fri, 13 Mar 1998 19:11:48 -0800 (PST)
Brett McCormick <brett@work.chicken.org>
Re: [HACKERS] casting & type comments
> > 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)

Fri, 13 Mar 1998 22:55:36 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] casting & type comments

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)

Fri, 13 Mar 1998 21:45:35 -0800 (PST)
Brett McCormick <brett@work.chicken.org>
Re: [HACKERS] casting & type comments
> 
> 
> 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)

Sat, 14 Mar 1998 01:08:38 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] casting & type comments
> 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

Mon, 16 Mar 1998 15:31:21 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] casting & type comments