Re: [HACKERS] Re: type coersion (was OR clause status) - Mailing list pgsql-hackers

From Thomas G. Lockhart
Subject Re: [HACKERS] Re: type coersion (was OR clause status)
Date
Msg-id 35CE22FF.4B30E754@alumni.caltech.edu
Whole thread Raw
In response to Re: [HACKERS] Re: type coersion (was OR clause status)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Re: type coersion (was OR clause status)  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [HACKERS] Re: type coersion (was OR clause status)  (Bruce Momjian <maillist@candle.pha.pa.us>)
Re: [HACKERS] Re: type coersion (was OR clause status)  (Bruce Momjian <maillist@candle.pha.pa.us>)
List 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

pgsql-hackers by date:

Previous
From: Roland Roberts
Date:
Subject: Re: [HACKERS] How do I find the table that an oid belongs to
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] thread-safe libpq and DBD::Pg