Re-added to TODO list :-)
* Fix typein/out functions to not be user-callable
> wieck@debis.com (Jan Wieck) writes:
> >>>> For that matter, why do we allow user expressions to call the type
> >>>> input/output functions at all? They're not really usable as SQL
> >>>> functions AFAICS...
>
> > Doing textout(byteaout(... really makes no sense. But being
> > able to do a textin(mytypeout(... does make sense for me.
> > Without that, there MUST be type casting support for
> > MYTYPE->TEXT in the parser.
>
> The real problem here is that the type system needs to have a notion
> of "C string" as a datatype so that the type input and output functions
> can be declared *properly* with the true nature of their inputs and
> results given correctly. Then typeain(typebout(typebvalue)) would work
> and textout(byteaout(...)) would be rejected, as it should be.
>
> The typechecking escape convention (zero in the proargtypes signature)
> should only be used for functions that really do accept any kind of
> datum. I think there are some (count(*) for one) but not many.
>
> The "C string" type is not quite a real type, because we don't want to
> let people declare columns of that type (I assume). OTOH it must be
> real enough to let people declare user-defined functions that accept or
> return it. Right now, the I/O functions for user-defined types are
> supposed to be declared to take or return type OPAQUE, but I think
> that pseudo-type is being used for too many different things.
>
> Obviously none of this is going to happen for 6.5, but it should go
> on the TODO list.
>
> regards, tom lane
>
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026