Re: New thoughts about indexing cross-type comparisons

From: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Dave Smith <dave(dot)smith(at)candata(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: New thoughts about indexing cross-type comparisons
Date: 2003-09-17 02:46:29
Message-ID: 3F67CB05.95D094CE@tpf.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
>
> Dave Smith <dave(dot)smith(at)candata(dot)com> writes:
> > If this is only dealing with constants, why not just explicitly add a
> > cast to the constant of the column type at the planner level. It would
> > solve this problem as well ...
>
> > create table test (f int2);
> > select * from test where f=cast('1981928928921' as int2);
> > ERROR: pg_atoi: error reading "1981928928921": Numerical result out of
> > range
>
> > select * from test where f=1981928928921;
> > f
> > ---
> > (0 rows)
>
> Uh, your own example points out why we can't just insert a cast to int2
> --- it changes the results. Or am I missing your point?

Because PG doesn't have the functionality to catch exceptions
until now, we can't call cast functions tentatively. But for
example, why should the pg_atoi error cause an unrecoverable
error immediately ? IMHO we should be able to call cast functions
internally without an anxiety to cause an unrecoverable error.

regards,
Hiroshi Inoue
http://www.geocities.jp/inocchichichi/psqlodbc/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruno Wolff III 2003-09-17 04:52:31 Re: Error compiling timestamp.c in 7.4
Previous Message Neil Conway 2003-09-17 02:30:22 locking for unique hash indexes