On Tue, 27 Jul 2004, Merlin Moncure wrote: > Greg Stark wrote: > > > > do it for multi-column keys. It seems it would be nice if some > syntax > > > > similar to (a,b,c) > (a1,b1,c1) worked for this. > > Hum. It would seem my intuition matches the SQL92 spec and Postgres > gets > > this > > wrong. > [...] > > Even if Postgres did this right I'm not sure that would solve your > index > > woes. > > I imagine the first thing Postgres would do is rewrite it into regular > > scalar > > expressions. Ideally the optimizer should be capable of then deducing > from > > the > > scalar expressions that an index scan would be useful. > > Wow. For once, the standard is my friend. Well, what has to be done? > :) Does pg do it the way it does for a reason? From the outside it > seems like the planner would have an easier job if it can make a field > by field comparison. > > Would a patch introducing the correct behavior (per the standard) be > accepted? It seems pretty complicated (not to mention the planner > issues).
Given the comment on make_row_op, /* * XXX it's really wrong to generate a simple AND combination for < <= * > >=. We probably need to invent a new runtime node type to handle * those correctly. For the moment, though, keep on doing this ... */ I'd expect it'd be accepted. ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
