Re: [HACKERS] current CVS snapshot of pgsql crash ... - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] current CVS snapshot of pgsql crash ...
Date
Msg-id 27593.931392206@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] current CVS snapshot of pgsql crash ...  (Bruce Momjian <maillist@candle.pha.pa.us>)
List pgsql-hackers
Bruce Momjian <maillist@candle.pha.pa.us> writes:
> Re-added to TODO list  :-)

>     * Fix typein/out functions to not be user-callable

Please rephrase it:

* Declare typein/out functions in pg_proc with a special "C string" data type

We want to type-check their uses correctly, not forbid their use.
        regards, tom lane


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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] inherited GROUP BY is busted ... I need some help here
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Priorities for 6.6