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