From: | "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | PostgreSQL-development <hackers(at)postgreSQL(dot)org> |
Subject: | Re: [HACKERS] Re: type coersion (was OR clause status) |
Date: | 1998-08-09 22:30:23 |
Message-ID: | 35CE22FF.4B30E754@alumni.caltech.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > Yes the handling does matter *in general*...
> This is all a good point. I wonder whether it wouldn't help to make
> the parser's initial assignment of types to constants depend on how
> big the constants are.
I agree that there is something to fix, including both of the indexing
example cases you are following. I've been seeing this as an opportunity
to fix sub-optimal utilization of indices, and my recent changes to
enhance the type conversion capabilities in the parser just put the
index handling in a harsher light.
If we come near release time, and no one has been able to penetrate the
index handling (to fix cases as simple as "where x = 1 + 1" which have
never worked) the we could fairly easily go back into the parser and
brute-force some non-general workarounds to get the few "worse than
before" cases hacked around.
If we _can_ get the index handling to work more generally, then we have
substantially enhanced the overall capabilities of Postgres.
So far, I haven't seen cases where the parser has tried to do "the wrong
thing", only cases where "the right thing" causes the index handling to
miss the boat...
- Tom
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 1998-08-09 23:01:49 | Re: [HACKERS] thread-safe libpq and DBD::Pg |
Previous Message | Roland Roberts | 1998-08-09 21:18:41 | Re: [HACKERS] How do I find the table that an oid belongs to |