From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: User defined I/O conversion casts |
Date: | 2008-08-29 15:38:38 |
Message-ID: | 48B817FE.6030906@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2008-08-29 15:55:11 | Re: New FSM allocation policy |
Previous Message | Tom Lane | 2008-08-29 15:15:02 | Re: New FSM allocation policy |