From: | Alex Pilosov <alex(at)pilosoft(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Olivier PRENANT <ohp(at)pyrenet(dot)fr>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Inet type how to? |
Date: | 2000-06-02 22:31:37 |
Message-ID: | Pine.BSO.4.10.10006021828410.8307-100000@spider.pilosoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 2 Jun 2000, Tom Lane wrote:
> >> None works. I tried. There is no type that can be cast to inet. And
> >> inet_in has a different calling sequence, and you can't really use that.
>
> > Added to TODO.
>
> If we had "C string" (or something like that) as a genuine type in the
> type system, then it would be possible/reasonable for the parser to
> understand
> textvariable::cstring::inet
> as a request to invoke text_out followed by inet_in.
>
> I think it'd be a real bad idea to invoke such conversions silently,
> since then we'd essentially have no type system at all (you could get
> from anything to anything else via cstring, so how can the thing check
> for errors?). But it'd be awful darn handy to be able to invoke the
> type i/o routines explicitly...
I think its a great idea. Is it just a matter of altering the catalog? Or
apparently we'd need postgres engine to know that cstring is a special
type and instead of looking for conversion routines it should use xxx_in
and yyy_out
I like it in any case. Last ditch do-not-use-unless-you-sure-its-what you
want thingy...
-alex
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2000-06-02 23:47:12 | Re: Problems with recent CVS versions and Solaris. |
Previous Message | Tom Lane | 2000-06-02 22:24:47 | Re: Inet type how to? |