Lists: | pgsql-hackers |
---|
From: | "Jim C(dot) Nasby" <jim(at)nasby(dot)net> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Status of Fix Domain Casting TODO |
Date: | 2007-01-01 21:54:21 |
Message-ID: | 20070101215420.GH71246@nasby.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
I'm wondering if Gevik has had any time for further work on
http://archives.postgresql.org/pgsql-hackers/2006-09/msg01738.php ?
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. My intention was to use that as the basis for an 'md5data'
domain (unfortunately, calling the domain simply 'md5' results in a
conflict with the built-in md5 function). So something to consider on
the domain casting is the case of casting from domain A to domain B to a
base type.
--
Jim Nasby jim(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
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-01 23:05:30 |
Message-ID: | 21051.1167692730@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
"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.
regards, tom lane
From: | "Andrew Dunstan" <andrew(at)dunslane(dot)net> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Status of Fix Domain Casting TODO |
Date: | 2007-01-02 00:30:40 |
Message-ID: | 4133.24.211.165.134.1167697840.squirrel@www.dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
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.
cheers
andrew
From: | "Jim C(dot) Nasby" <jim(at)nasby(dot)net> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Status of Fix Domain Casting TODO |
Date: | 2007-01-02 10:14:34 |
Message-ID: | 20070102101433.GB71246@nasby.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
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().
--
Jim Nasby jim(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
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: | 459A748B.5090002@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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.
HTH
cheers
andrew
From: | elein <elein(at)varlena(dot)com> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | "Jim C(dot) Nasby" <jim(at)nasby(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Status of Fix Domain Casting TODO |
Date: | 2007-01-05 23:15:59 |
Message-ID: | 20070105231559.GL24367@varlena.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
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(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.
>
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