Re: Fwd: Filter by Selection on Grid
| От | Robins Tharakan |
|---|---|
| Тема | Re: Fwd: Filter by Selection on Grid |
| Дата | |
| Msg-id | 36af4bed0802060942o17879342yfde8f4c274b76c79@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Fwd: Filter by Selection on Grid ("Dave Page" <dpage@postgresql.org>) |
| Ответы |
Re: Fwd: Filter by Selection on Grid
|
| Список | pgadmin-hackers |
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
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@postgresql.org>
Date: Feb 6, 2008 5:11 PM
Subject: Re: [pgadmin-hackers] Fwd: Filter by Selection on Grid
To: Robins Tharakan <tharakan@gmail.com>
Cc: pgadmin-hackers@postgresql.org
cheers, Dave.
From: Dave Page <dpage@postgresql.org>
Date: Feb 6, 2008 5:11 PM
Subject: Re: [pgadmin-hackers] Fwd: Filter by Selection on Grid
To: Robins Tharakan <tharakan@gmail.com>
Cc: pgadmin-hackers@postgresql.org
On Feb 6, 2008 11:02 AM, Robins Tharakan <tharakan@gmail.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 ;-)> > ... 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.
cheers, Dave.
Вложения
В списке pgadmin-hackers по дате отправления: