Re: [HACKERS] 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 [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Status of Fix Domain Casting TODO
On Mon, Jan 01, 2007 at 06:30:40PM -0600, Andrew Dunstan wrote: Tom Lane wrote: Jim C. Nasby [EMAIL PROTECTED] 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[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Status of Fix Domain Casting TODO
Jim C. Nasby wrote: On Mon, Jan 01, 2007 at 06:30:40PM -0600, Andrew Dunstan wrote: Tom Lane wrote: Jim C. Nasby [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] Status of Fix Domain Casting TODO
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[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Status of Fix Domain Casting TODO
Jim C. Nasby [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Status of Fix Domain Casting TODO
Tom Lane wrote: Jim C. Nasby [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
