Skip site navigation (1) Skip section navigation (2)

Re: Status of Fix Domain Casting TODO

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: "Jim C(dot) Nasby" <jim(at)nasby(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Status of Fix Domain Casting TODO
Date: 2007-01-02 15:04:43
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Jim C. Nasby wrote:
> On Mon, Jan 01, 2007 at 06:30:40PM -0600, Andrew Dunstan wrote:
>> Tom Lane wrote:
>>> "Jim C. Nasby" <jim(at)nasby(dot)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.




In response to


pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2007-01-02 15:12:18
Subject: Re: Reverse-sort indexes and NULLS FIRST/LAST sorting
Previous:From: Tom LaneDate: 2007-01-02 15:00:24
Subject: Re: TODO: Add a GUC to control whether BEGIN inside

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group