Re: [HACKERS] OR clause status

From: "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu>
To: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
Cc: daveh(at)insightdist(dot)com, hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] OR clause status
Date: 1998-08-06 06:09:31
Message-ID: 35C9489B.781E162@alumni.caltech.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> > I think the OID auto-casting should be very easy
> > Once the development tree becomes unbroken...
> Yes, I think there are some very good reasons to evaluate functions on
> constants inside the parser.

I wasn't actually suggesting making real changes to the parser. I
_think_ I can get the OID vs int4 coersion problem fixed with a one-line
change to a header file, but need a working tree to do it :(

Any progress on getting the tree to compile? Are there some people who
don't see a problem??

> There are some operations that look at
> index selectivity that need to know the constant value, rather than
> knowing if the function returns an int. For example x > 3 looks at
> the pg_statistics table to see max/min values.
>
> You certainly don't want to be evaluating functions on constants
> inside the optimizer.

?? Why not? It is an optimization after all. I have never looked at the
optimizer code however. Are you saying that the current optimizer
doesn't have a pass or phase where functions could be evaluated? Should
we add a pass to do this? I've been a bit worried about coding too many
optimizations into the parser, since they might become pretty obscure
buried in there.

- Tom

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas G. Lockhart 1998-08-06 06:17:18 Re: [HACKERS] Declare Cursor question again
Previous Message Peter T Mount 1998-08-06 05:59:49 Re: [HACKERS] Large objects names