Re: [HACKERS] Interesting behaviour !

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Constantin Teodorescu <teo(at)flex(dot)ro>
Cc: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>, Hannu Krosing <hannu(at)trust(dot)ee>, "pgsql-hackers(at)postgreSQL(dot)org" <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: [HACKERS] Interesting behaviour !
Date: 1999-07-14 16:17:52
Message-ID: 25922.931969072@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Constantin Teodorescu <teo(at)flex(dot)ro> writes:
> Bruce Momjian wrote:
>> I thought we had this fixed in 6.5. Is that what you are using?

> Yes!

It's not fixed, obviously. We talked about the issue a while back,
but it isn't 100% clear what the most reasonable fix is. Just making
the parser label small constants as int2 rather than int4 is no
answer; that'll only move the problem over to int4 tables :-(.

I have not looked closely at the parse trees produced for this sort
of thing, but if we are lucky they come out like
var int2eq (int4toint2(int4constant))
in which case the constant-subexpression-folding pass that I want to
add would solve the problem by reducing the righthand side to a simple
constant.

But it's more likely that the parser is producing
int2toint4(var) int4eq int4constant
in which case it would take some actual intelligence to decide that this
could and should be converted to the other form. I'd still be inclined
to tackle the issue in a post-rewriter, pre-planner pass over the tree.

regards, tom lane

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1999-07-14 16:27:07 Re: [HACKERS] MAX Query length
Previous Message Thomas Lockhart 1999-07-14 16:13:39 Re: [HACKERS] Counting bool flags in a complex query