RE: [HACKERS] Interesting behaviour !

From: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
To: "Thomas Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Constantin Teodorescu" <teo(at)flex(dot)ro>, "Bruce Momjian" <maillist(at)candle(dot)pha(dot)pa(dot)us>, "Hannu Krosing" <hannu(at)trust(dot)ee>, <pgsql-hackers(at)postgreSQL(dot)org>
Subject: RE: [HACKERS] Interesting behaviour !
Date: 1999-07-16 00:55:32
Message-ID: 000c01becf25$e8047b60$2801007e@cadzone.tpf.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
> > Each type has a typeinput(char * => type ) proc and a typeoutput(
> > type -> char *) proc.
> > Doesn't int2in(int4out()) convert int4 to int2 ?
> > However,typeinput proc causes elog(ERROR) in most cases if it
> > couldn't convert correctly.
>
> Conversion using an intermediate string is possible, but not the
> preferred technique.
>

Every type of PostgreSQL must have typeinput/typeoutput procs.
So this technique doesn't need new procs/operators any more.
Isn't it an advantage ?

> The "automatic type coersion" code, used earlier in the parser, uses
> the convention that any single-argument function taking the source
> type as input and with the same name as the target type can be used
> for type conversion. For example, the function int4(int2) would
> convert int2 to int4. There are now routines in the parser for
> choosing conversion strategies and for finding candidates, and these
> could be reused for similar purposes when trying to match index
> arguments.
>

It seems reasonable.
But I'm afraid that the defintion of new type requires many functions
of type conversion.

Regards.

Hiroshi Inoue
Inoue(at)tpf(dot)co(dot)jp

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hiroshi Inoue 1999-07-16 01:09:08 RE: [HACKERS] Interesting behaviour !
Previous Message Ole Gjerde 1999-07-16 00:23:44 Re: [HACKERS] Interesting index/LIKE/join slowness problems