On mán, 2007-01-01 at 14:21 -0600, [EMAIL PROTECTED] wrote:
> Within the context of the function (after calling), these variables are
> constant and I'm attempting to use my OR syntax as shorthand to avoid
> having to use a dynamic statement *only* because of this situation.
> As I've mentioned,
Ragnar wrote:
Reguardless of the issue whether pl/pgsql could be expected to
optimize this case, I find it difficult to imagine a scenario
where this kind of coding makes sense.
I understand that in some cases on would like to do this with
a *variable* to simplify logic, but what possible gain c
[EMAIL PROTECTED] writes:
> I was referring to the situation where one has this in a WHERE clause:
>((vConstant IS NULL) OR (Table.IndexedCol = vConstant))
> where vConstant is a *constant* parameter in a pl/pgsql function.
My mistake, I was thinking of Table.IndexedCol IS NULL.
> In the late
On mið, 2006-12-27 at 11:02 -0600, [EMAIL PROTECTED] wrote:
>
> I was referring to the situation where one has this in a WHERE clause:
>
>((vConstant IS NULL) OR (Table.IndexedCol = vConstant))
>
> where vConstant is a *constant* parameter in a pl/pgsql function.
Reguardless of the issue wh
Tom Lane wrote:
[EMAIL PROTECTED] writes:
I would submit that in that situation, it would be
reasonable for a user to expect my suggested syntax to still use the
indicated indexes.
The only thing that will make that work is if "indexed_col IS NULL" were
an indexable condition, which it isn't
[EMAIL PROTECTED] writes:
> I would submit that in that situation, it would be
> reasonable for a user to expect my suggested syntax to still use the
> indicated indexes.
The only thing that will make that work is if "indexed_col IS NULL" were
an indexable condition, which it isn't because the P
[EMAIL PROTECTED] wrote:
Tom Lane wrote:
you're still gonna lose because those are variables not constants ...
Well, that *is* what I'm hoping to do. I understand how (0 IS NULL) is
different from (variable IS NULL), but isn't it reasonable to expect
that PG could evaluate that expression o
Tom Lane wrote:
Well, you could update --- 8.2 contains code to recognize that the IS
NULL expression is constant, but prior releases do not.
That's excellent to hear -- I'd missed that in my perusing of the
changelogs between 8.0.x and 8.2. That does give me one more reason to
upgrade. It
[EMAIL PROTECTED] writes:
>select * from t where c1 = 75000;
>select * from t where ((0 is null) OR (c1 = 75000));
> The first one properly uses the index on c1, the second does not.
> Obviously, a human looking at the second one would realize it's
> essentially identical to the first an
