From: | "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu> |
---|---|
To: | Vadim Mikheev <vadim(at)krs(dot)ru> |
Cc: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>, tgl(at)sss(dot)pgh(dot)pa(dot)us, hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Re: type coersion (was OR clause status) |
Date: | 1998-08-18 05:22:17 |
Message-ID: | 35D90F89.4612B7AD@alumni.caltech.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Just let me note that function calls on constants is problem not
> only for indices using. Call lower() for each tuple in
> WHERE a = lower('bbb') is always bad - lower() eats memory...
Sure, so we want to evaluate as a constant. I've found a place in the
code where a function gets evaluated immediately; don't remember where
but it looked like an interesting possibility.
> > > How about character string comparisons using indexes?
> Parser could use type_in()/type_out() funcs to do type
> coersion...
That is what it used to try to do. But I don't think that generalizes
very well. For example, at the moment floating point numbers without
fractional parts are printed without a decimal point or trailing digits,
but we could decide to format them with a ".0" at the end. Then they
couldn't be converted to an integer...
> > Vadim, will the executor know how to use a PARAM_EXEC node in any
> > context, or will we have to do some coding to get it recognized
> > outside of subselects? I'll need to figure out how to build one too,
> > I suppose...
> I'm not sure... But imho, PARAM_EXEC could be usefull for
> now() etc funcs - for non-variant funcs I would suggest
> just evaluate them in parser...
But it could be used for every function called with constants, right? If
it works for everything, why bother with other special cases?
- Tom
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas G. Lockhart | 1998-08-18 05:33:37 | Re: [HACKERS] odd pg_dump output? |
Previous Message | t-ishii | 1998-08-18 05:01:03 | odd pg_dump output? |