Re: Fwd: Filter by Selection on Grid - Mailing list pgadmin-hackers
| From | Robins Tharakan |
|---|---|
| Subject | Re: Fwd: Filter by Selection on Grid |
| Date | |
| Msg-id | 36af4bed0802100747j54354d80x7002ea23b485d109@mail.gmail.com Whole thread Raw |
| In response to | Re: Fwd: Filter by Selection on Grid ("Robins Tharakan" <tharakan@gmail.com>) |
| Responses |
Re: Fwd: Filter by Selection on Grid
Re: Fwd: Filter by Selection on Grid |
| List | pgadmin-hackers |
As promised, here are two other patches, one each for the following:
1. IS DISTINCT FROM to replace '<>' in the WHERE conditions
2. Documentation addition in the html about the recent Selection/Sort changes.
Still working on the crash regarding thread->IsRunning().
Robins
---------- Forwarded message ----------
From: Robins Tharakan <tharakan@gmail.com>
Date: Feb 10, 2008 12:22 AM
Subject: Re: [pgadmin-hackers] Fwd: Filter by Selection on Grid
To: Dave Page <dpage@postgresql.org>
Cc: pgadmin-hackers@postgresql.org
Hi,
Hmmm... although I did do a complete svn co before submitting my previous patch, I think I am making it all complicated by bringing in too many things together.
I think you're right. Probably its better to do one thing at a time :)
Attached is a patch to correct the Sort issue. It does an in-place string replace if the sort order is changed by the user.
Once this goes ahead, I have a few more patches coming up:
1. IS DISTINCT FROM to replace '<>' in the WHERE conditions
2. Documentation addition in the html about the recent Selection/Sort changes.
3. Ensure that a thread->IsRunning() in frmEdit.cpp (line: ~414) doesn't cause a crash.
Robins Tharakan
From: Robins Tharakan <tharakan@gmail.com>
Date: Feb 10, 2008 12:22 AM
Subject: Re: [pgadmin-hackers] Fwd: Filter by Selection on Grid
To: Dave Page <dpage@postgresql.org>
Cc: pgadmin-hackers@postgresql.org
Hi,
Hmmm... although I did do a complete svn co before submitting my previous patch, I think I am making it all complicated by bringing in too many things together.
I think you're right. Probably its better to do one thing at a time :)
Attached is a patch to correct the Sort issue. It does an in-place string replace if the sort order is changed by the user.
Once this goes ahead, I have a few more patches coming up:
1. IS DISTINCT FROM to replace '<>' in the WHERE conditions
2. Documentation addition in the html about the recent Selection/Sort changes.
3. Ensure that a thread->IsRunning() in frmEdit.cpp (line: ~414) doesn't cause a crash.
Robins Tharakan
Date: Feb 7, 2008 4:50 PM
Subject: Re: [pgadmin-hackers] Fwd: Filter by Selection on Grid
To: Robins Tharakan <tharakan@gmail.com>
Cc: pgadmin-hackers@postgresql.org
Subject: Re: [pgadmin-hackers] Fwd: Filter by Selection on Grid
To: Robins Tharakan <tharakan@gmail.com>
Cc: pgadmin-hackers@postgresql.org
Hi.
On Feb 6, 2008 5:42 PM, Robins Tharakan <tharakan@gmail.com> wrote:
> 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 ?
I think you misunderstood my previous message. I committed your patch
to SVN, and cleaned up the formatting, added the test to ensure thread
is valid, and added the proper quoting.
So at this point you should svn update and start working from svn
trunk again to add the IS DISTINCT FROM and duplicate sort prevention.
> 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 ?
Well the code you are adding is primarily a shortcut which is likely
not going to be used by someone at the same time as they manually
author filter strings - so I say we just document the potential issue
and leave it at that. I'm more concerned about the sorting side where
it should be trivial to detect the duplicate.
Speaking of which, this feature should have a paragraph or two in the
docs - I forgot to mention that, sorry (we've been waiting to release
8.3 for months so I'm somewhat rusty at this!).
Thanks, Dave.
On Feb 6, 2008 5:42 PM, Robins Tharakan <tharakan@gmail.com> wrote:
> 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 ?
to SVN, and cleaned up the formatting, added the test to ensure thread
is valid, and added the proper quoting.
So at this point you should svn update and start working from svn
trunk again to add the IS DISTINCT FROM and duplicate sort prevention.
> 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 ?
not going to be used by someone at the same time as they manually
author filter strings - so I say we just document the potential issue
and leave it at that. I'm more concerned about the sorting side where
it should be trivial to detect the duplicate.
Speaking of which, this feature should have a paragraph or two in the
docs - I forgot to mention that, sorry (we've been waiting to release
8.3 for months so I'm somewhat rusty at this!).
Thanks, Dave.
Attachment
pgadmin-hackers by date: