Re: User defined I/O conversion casts

Since 8.3, the system provides automatic I/O conversion casts between
the built-in string types and other types, but there's currently no way
for a user to declare additional casts using the I/O functions. You can
always create a simple SQL function to do that, but it seems like we
should provide a direct interface for that. I propose the syntax:

CREATE CAST (<source> AS <target>) WITH INOUT [AS IMPLICIT | AS ASSIGNMENT]

Conveniently, INOUT is already a col_name_keyword, so this works without
any conflicts or new keywords.

This would be very useful for those who want relax some built-in
automatic assignment casts to implicit casts, 8.2 style, as well as
anyone creating a user-defined data type with casts that can be
implemented with the I/O functions.

Patch attached. I'm using a magic OID "1" in pg_cast.castfunc field to
mark these extra I/O conversion casts. Perhaps we want to have a
separate field for that or something, but that was a quick way to get
started.

Anyone else think this is a good idea? Thoughts on the implementation?

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

> Since 8.3, the system provides automatic I/O conversion casts between
> the built-in string types and other types, but there's currently no way
> for a user to declare additional casts using the I/O functions. You can
> always create a simple SQL function to do that, but it seems like we
> should provide a direct interface for that. I propose the syntax:
>
> CREATE CAST (<source> AS <target>) WITH INOUT [AS IMPLICIT | AS ASSIGNMENT]

> Anyone else think this is a good idea? Thoughts on the implementation?

Agree, that task causes too often for me. Although using separate boolean column
looks more preferable than special value for OID.

--
Teodor Sigaev E-mail: teodor(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/

Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> Patch attached. I'm using a magic OID "1" in pg_cast.castfunc field to
> mark these extra I/O conversion casts.

Ugh. That's really unacceptable (doesn't it make the oidjoins
regression test fail?),

I think that as things stand at the moment, you can get I/O conversion
casts to work for a user-defined type by making it be of string
category. Maybe that would be an easier way to get the effect.

regards, tom lane

Tom Lane wrote:
> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
>> Patch attached. I'm using a magic OID "1" in pg_cast.castfunc field to
>> mark these extra I/O conversion casts.
>
> Ugh. That's really unacceptable (doesn't it make the oidjoins
> regression test fail?),

Yeah, it does if you create a cast like that. And pg_dump/restore will
need to be taught about it as well.

> I think that as things stand at the moment, you can get I/O conversion
> casts to work for a user-defined type by making it be of string
> category. Maybe that would be an easier way to get the effect.

Hmm. That would be sensible only for types that are, well, strings. Not
if you wanted to make the cast from, say, int4 to text implicit.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

(Resurrecting an old thread.)

Tom Lane wrote:
> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
>> Patch attached. I'm using a magic OID "1" in pg_cast.castfunc field to
>> mark these extra I/O conversion casts.
>
> Ugh. That's really unacceptable (doesn't it make the oidjoins
> regression test fail?),

Yeah, a magical OID clearly has some issues. A new field in pg_cast is
the obvious alternative. How about adding a "castmethod" char field,
with values:
b = binary-compatible cast (CREATE CAST ... WITHOUT FUNCTION)
i = I/O coercion cast (the new beast, CREATE CAST ... WITH INOUT)
f = use cast function specified in castfunc field.

castfunc is 0 for methods b and i.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> Yeah, a magical OID clearly has some issues. A new field in pg_cast is
> the obvious alternative. How about adding a "castmethod" char field,
> with values:
> b = binary-compatible cast (CREATE CAST ... WITHOUT FUNCTION)
> i = I/O coercion cast (the new beast, CREATE CAST ... WITH INOUT)
> f = use cast function specified in castfunc field.
> castfunc is 0 for methods b and i.

Seems sane to me. If you do that, please add a check in the opr_sanity
regression test that castfunc is nonzero if and only if castmethod is f.

regards, tom lane

Tom Lane wrote:
> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
>> Yeah, a magical OID clearly has some issues. A new field in pg_cast is
>> the obvious alternative. How about adding a "castmethod" char field,
>> with values:
>> b = binary-compatible cast (CREATE CAST ... WITHOUT FUNCTION)
>> i = I/O coercion cast (the new beast, CREATE CAST ... WITH INOUT)
>> f = use cast function specified in castfunc field.
>> castfunc is 0 for methods b and i.
>
> Seems sane to me. If you do that, please add a check in the opr_sanity
> regression test that castfunc is nonzero if and only if castmethod is f.

Ok, will do.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

Tom Lane wrote:
> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
>> Yeah, a magical OID clearly has some issues. A new field in pg_cast is
>> the obvious alternative. How about adding a "castmethod" char field,
>> with values:
>> b = binary-compatible cast (CREATE CAST ... WITHOUT FUNCTION)
>> i = I/O coercion cast (the new beast, CREATE CAST ... WITH INOUT)
>> f = use cast function specified in castfunc field.
>> castfunc is 0 for methods b and i.
>
> Seems sane to me. If you do that, please add a check in the opr_sanity
> regression test that castfunc is nonzero if and only if castmethod is f.

Here's a patch. It seems pretty straightforward, I'll apply this
tomorrow, barring objections. Note to self: bump the catalog version.

BTW, it looks like we don't have any test cases for the CREATE CAST
command. I think I'll add one.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> Here's a patch. It seems pretty straightforward, I'll apply this
> tomorrow, barring objections. Note to self: bump the catalog version.

Looks sane in a fast once-over. I didn't cross-check the pg_cast.h
data changes, but that's what the regression test check is for ;-)

regards, tom lane