Re: [HACKERS] current CVS snapshot of pgsql crash ...

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