Re: Fwd: Filter by Selection on Grid

Hi,

The attached patch does this:
1. Sanitize the if-else bracket style for the earlier patch.
2. Use 'IS DISTINCT FROM' instead of <> in an exclusion condition.

Two issues remain that I can't resolve:
1. Rightly as you point out thread->IsRunning() needs to be called only if
it exists. On rigorous testing the application bombs if this thread is
non-existent (backtrace attached). Any good way to check whether a thread is
running ? Any flag etc ?
2. The case of selection and deselection of the same field name can
(ideally) cause a bit of a complication.
Consider this:
a. M=10 AND M <> 10
b. M = 10 AND (N = 10 OR M <> 10)
If we are to filter out the old test condition replacing it with a new test
condition using a string parser how does it understand the difference
between case (a) and case (b) ? Unless I am missing the point, I think to
effectively resolve this would need a inverted tree structure for the where
clause which I think is a bit of an overkill for now ?

Any hints for a better way to work around these ?

*Robins*

---------- Forwarded message ----------
From: Dave Page <dpage(at)postgresql(dot)org>
Date: Feb 6, 2008 5:11 PM
Subject: Re: [pgadmin-hackers] Fwd: Filter by Selection on Grid
To: Robins Tharakan <tharakan(at)gmail(dot)com>
Cc: pgadmin-hackers(at)postgresql(dot)org

On Feb 6, 2008 11:02 AM, Robins Tharakan <tharakan(at)gmail(dot)com> wrote:
> > ... snip ...
> Sure ! Points that I'll take into account from now on.
>
>
> > One other thing I noticed that should be fixed in a new patch - if you
> > sort ascending on a column, and then sort descending, it will add
> > both. It should remove the ascending and replace it with the
> > descending sort.
>
> True... and one more thing that I was working on (when I responded to
> Guillaume the other day) was that if a person does an 'exclude by
selection'
> on a field with a value = 10, we simply put a [WHERE] value <> 10
filter...
> however I think this is incomplete.
>
> instead of
> WHERE value <> 10
>
> we should rather put
>
> WHERE (value <> 10 OR value IS NULL)
> Or
> WHERE (value IS DISTINCT FROM 10)
>
> This is because as per the UI, the user does not want value 10, but he
still
> would want a NULL value in the records.

Yes, thats a good point. I look forward to seeing the patch ;-)

cheers, Dave.