Re: Status of Fix Domain Casting TODO

On Tue, Jan 02, 2007 at 10:04:43AM -0500, Andrew Dunstan wrote:
> Jim C. Nasby wrote:
> >On Mon, Jan 01, 2007 at 06:30:40PM -0600, Andrew Dunstan wrote:
> >  
> >>Tom Lane wrote:
> >>    
> >>>"Jim C. Nasby" <jim@nasby.net> writes:
> >>>      
> >>>>FWIW, I'm running into this trying to create a 'raw' domain that would
> >>>>automagically convert hex strings into actual binary data for storage in
> >>>>a bytea.
> >>>>        
> >>>I think you've got 0 chance of implementing that as a domain rather than
> >>>an independent type.  Without or without revisions in the casting rules,
> >>>a domain has not got its own I/O functions, and never will.
> >>>      
> >>This might be less of an issue if we allowed such IO functions to be
> >>written in a loadable PL rather than in C.
> >>    
> >
> >I'm confused... couldn't I just write a cast function? Or is that what's
> >meant by I/O functions?
> >
> >And yes, in this case I should be able to accomplish what I'm looking
> >for just using encode() and decode().
> >  
> 
> The I/O functions are set up by the INPUT and OUTPUT params of the 
> CREATE TYPE statement. They convert to and from the type 'cstring'. If 
> you want to change the way a piece of data is read/produced (e.g. 
> automatically encode/decode the value) these are what you would need. A 
> domain is in effect a constrained type. But it inherits the I/O 
> functions of its base type. But constraints are not what you want - you 
> want to deal with representation, which is the property dealt with by 
> I/O functions - their fundamental purpose is to convert between external 
> and internal representation.
> 
You can fake out the input function by putting a check clause on
the type definition.  I agree there should be hooks allowing 
input/output functions to be written in pls.

late to the thread, again,

--elein