Thread: ...

...

From
News Subsystem
Date:
Thu, 17 Jan 2013 05:56:02 -0800 (PST)Jan 2013 05:56:02 -0800 (PST)
X-Newsgroups: pgsql.interfaces.pgadmin.support
Date: Thu, 17 Jan 2013 05:56:02 -0800 (PST)
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com;
posting-host=79.121.57.171;posting-account=Qgz6DQoAAABy7twg8l6on0iP0KA6BAvN
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <2cf797a2-b773-495b-b310-5f27b1a34412@googlegroups.com>
Subject: Live Result or filtering rows by another table?
From: durumdara@gmail.com
Injection-Date: Thu, 17 Jan 2013 13:56:02 +0000
Content-Type: text/plain; charset=ISO-8859-1
To: pgadmin-support@postgresql.org

Dear Support!

Will you plan to support "live results" in pgAdmin's future versions?

To avoid misunderstand:
Live or sensitive queries can edited.
If the query doesn't contains any joins, or fields from other tables, the queries can be live/sensitive, and the result
iseditable.
 

It is very useful thing when we want to edit just specific rows without opening two subwindows, and copy the row ids
oneby one.
 

For example:
select * from details where master_id is in (select id from master where long condition)

Or can I use subqueries in the filter of the data edit window?

Thanks for your help: dd



Re:

From
Edson Richter
Date:
Em 17/01/2013 11:56, News Subsystem escreveu:
>          Thu, 17 Jan 2013 05:56:02 -0800 (PST)
>   Jan 2013 05:56:02 -0800 (PST)
> X-Newsgroups: pgsql.interfaces.pgadmin.support
> Date: Thu, 17 Jan 2013 05:56:02 -0800 (PST)
> Complaints-To: groups-abuse@google.com
> Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=79.121.57.171;
>   posting-account=Qgz6DQoAAABy7twg8l6on0iP0KA6BAvN
> User-Agent: G2/1.0
> MIME-Version: 1.0
> Message-ID: <2cf797a2-b773-495b-b310-5f27b1a34412@googlegroups.com>
> Subject: Live Result or filtering rows by another table?
> From: durumdara@gmail.com
> Injection-Date: Thu, 17 Jan 2013 13:56:02 +0000
> Content-Type: text/plain; charset=ISO-8859-1
> To: pgadmin-support@postgresql.org
>
> Dear Support!
>
> Will you plan to support "live results" in pgAdmin's future versions?
>
> To avoid misunderstand:
> Live or sensitive queries can edited.
> If the query doesn't contains any joins, or fields from other tables, the queries can be live/sensitive, and the
resultis editable.
 
>
> It is very useful thing when we want to edit just specific rows without opening two subwindows, and copy the row ids
oneby one.
 
>
> For example:
> select * from details where master_id is in (select id from master where long condition)
>
> Or can I use subqueries in the filter of the data edit window?
>
> Thanks for your help: dd
>
>
I think the feature you are looking for is obtained using right click 
over table and selecting "View data... filtered rows".
It's live and editable.

Regards,


Edson Richter



Re: Editable resultset

From
Michal Kozusznik
Date:
I think the feature you are looking for is obtained using right click 
over table and selecting "View data... filtered rows".
> It's live and editable.
>
>

Yes it is. But is not comfy enough for daily work
It is implemented very well in MySQL software (Query Browser and 
Workbench). You can edit resultset retrieved  by SELECT statement since 
it's identified by PK or Unique key, right after executing this statement.
The method provided by pgadmin is not always efficient. There are a few 
reasons:
- you cannot define columns set displayed in the grid - with a lot 
columns in a table, while not all fit the window, working with it is 
annoying
- you cannot change order of displayed columns - as above
- using filter and sort tabs is significantly slower then writing SELECT 
in query window
- usually (from experience) you start to work with query window. Then 
after got result, you have to execute select via View Data just to be 
able to edit it. Sometimes writing update query is faster (again, from 
experience)

So, I also vote to make resultsets retrieved by select statement editable.

with regards






Re: Editable resultset

From
Dave Page
Date:
On Thu, Jan 17, 2013 at 3:47 PM, Michal Kozusznik
<kozusznik.michal@ifortuna.cz> wrote:
> I think the feature you are looking for is obtained using right click over
> table and selecting "View data... filtered rows".
>>
>> It's live and editable.
>>
>>
>
> Yes it is. But is not comfy enough for daily work
> It is implemented very well in MySQL software (Query Browser and Workbench).
> You can edit resultset retrieved  by SELECT statement since it's identified
> by PK or Unique key, right after executing this statement.
> The method provided by pgadmin is not always efficient. There are a few
> reasons:
> - you cannot define columns set displayed in the grid - with a lot columns
> in a table, while not all fit the window, working with it is annoying
> - you cannot change order of displayed columns - as above
> - using filter and sort tabs is significantly slower then writing SELECT in
> query window
> - usually (from experience) you start to work with query window. Then after
> got result, you have to execute select via View Data just to be able to edit
> it. Sometimes writing update query is faster (again, from experience)
>
> So, I also vote to make resultsets retrieved by select statement editable.

It's not a case of voting I'm afraid. It's finding someone with the
time and desire to implement the feature.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



Re: Editable resultset

From
Michal Kozusznik
Date:
On 17.1.2013 16:54, Dave Page wrote:
> It's not a case of voting I'm afraid. It's finding someone with the
> time and desire to implement the feature.
>

When team working on pgAdmin will get rid of all bugs (hope it is not 
infinity collection) then they may start on improving the product.
I know pgAdmin is open source and its for free. But it is not reason to 
answer this way. I noticed that any improvement request is rejected with 
comment "do it your self". In my opinion it's a shame.

It's quite clear that some features are just unfinished prototypes and 
no one wants to touch this  again (being afraid to crash it completely). 
Unfortunately it tells everything about quality of code. But one day it 
must be refactored and some features must be cleaned up. So why to not 
start improving pgAdmin today? Is it really matter of time or desire 
(rather reluctance)?

with regards
MK




Re: Editable resultset

From
Dave Page
Date:
On Mon, Jan 21, 2013 at 10:50 AM, Michal Kozusznik
<kozusznik.michal@ifortuna.cz> wrote:
> On 17.1.2013 16:54, Dave Page wrote:
>>
>> It's not a case of voting I'm afraid. It's finding someone with the
>> time and desire to implement the feature.
>>
>
> When team working on pgAdmin will get rid of all bugs (hope it is not
> infinity collection) then they may start on improving the product.
> I know pgAdmin is open source and its for free. But it is not reason to
> answer this way. I noticed that any improvement request is rejected with
> comment "do it your self". In my opinion it's a shame.

Well, much as I'd love to have the time to implement every worthwhile
feature that people request, I simply don't, and I know Guillaume
doesn't either. So, there really isn't much I can do other than to
suggest contributing code yourself. That is, after all, how all of us
got involved with PostgreSQL, so you'll have to excuse me for not
thinking it's particularly weird.

> It's quite clear that some features are just unfinished prototypes and no
> one wants to touch this  again (being afraid to crash it completely).

There are 2 features where that sort-of but not quite applies. The
Query Builder, which was half-baked and never should have been
committed in my opinion - what is disabled by default in any build,
and only affects anything if you explicitly enable it, and second, the
Debugger which has never been as stable as it should be, something
which only came to light *after* Mac and Solaris builds were tested
where it became apparently that the threading code in it doesn't work
consistently across all platforms (and that code comes from
wxWidgets).

But, I've had one of the team at EnterpriseDB working tirelessly for
the last 2 - 3 months to rewrite that from the ground-up for the next
release.

> Unfortunately it tells everything about quality of code. But one day it must
> be refactored and some features must be cleaned up. So why to not start
> improving pgAdmin today? Is it really matter of time or desire (rather
> reluctance)?

Yes, it's time, and lack of people willing to contribute to the
project. And the fact that there are hundreds of thousands of lines of
code, and more features being added to PostgreSQL all the time which
also need to be supported.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



Re: Editable resultset

From
Martin French
Date:
<tt><font size="2">> <br /> > When team working on pgAdmin will get rid of all bugs (hope it is not <br /> >
infinitycollection) then they may start on improving the product.<br /> > I know pgAdmin is open source and its for
free.But it is not reason to <br /> > answer this way. I noticed that any improvement request is rejected with <br
/>> comment "do it your self". In my opinion it's a shame.<br /></font></tt><br /><tt><font size="2">There are a
numberof a people that are willing, and do contribute to various elements of the PostgreSQL projects, if they didn't
thenPostgreSQL and PgAgminIII wouldn't exist in it's current form! Obviously more contributors would possibly free up
sometime for others [contributors], but that doesn't necessarily mean that they'll have time to work on new features.
</font></tt><br/><br /><tt><font size="2">I, personally; am quite happy to "Chip in" and contribute to a code base that
Iwork with day in and day out, after all, isn't that what open source is all about?</font></tt><br /><font
face="sans-serif"size="2"><br /> =============================================<br /><br /> Romax Technology Limited<br
/>Rutherford House<br /> Nottingham Science & Technology Park<br /> Nottingham, <br /> NG7 2PZ<br /> England<br
/><br/> Telephone numbers:<br /> +44 (0)115 951 88 00 (main)<br /><br /> For other office locations see:<br /></font><a
href="http://www.romaxtech.com/Contact"><fontface="sans-serif"
size="2">http://www.romaxtech.com/Contact</font></a><fontface="sans-serif" size="2"><br />
=================================<br/> ===============<br /> E-mail: info@romaxtech.com<br /> Website: </font><a
href="www.romaxtech.com"><fontface="sans-serif" size="2">www.romaxtech.com</font></a><font face="sans-serif"
size="2"><br/> =================================<br /><br /> ================<br /> Confidentiality Statement<br />
Thistransmission is for the addressee only and contains information that is confidential and privileged.<br /> Unless
youare the named addressee, or authorised to receive it on behalf of the addressee <br /> you may not copy or use it,
ordisclose it to anyone else. <br /> If you have received this transmission in error please delete from your system and
contactthe sender. Thank you for your cooperation.<br /> =================================================</font> 

Re: Editable resultset

From
Guillaume Lelarge
Date:
As I'm trying to get back as I now have some time, I just discovered
this mail.

On Mon, 2013-01-21 at 11:08 +0000, Dave Page wrote:
> On Mon, Jan 21, 2013 at 10:50 AM, Michal Kozusznik
> <kozusznik.michal@ifortuna.cz> wrote:
> > On 17.1.2013 16:54, Dave Page wrote:
> >>
> >> It's not a case of voting I'm afraid. It's finding someone with the
> >> time and desire to implement the feature.
> >>
> >
> > When team working on pgAdmin will get rid of all bugs (hope it is not
> > infinity collection) then they may start on improving the product.
> > I know pgAdmin is open source and its for free. But it is not reason to
> > answer this way. I noticed that any improvement request is rejected with
> > comment "do it your self". In my opinion it's a shame.
> 
> Well, much as I'd love to have the time to implement every worthwhile
> feature that people request, I simply don't, and I know Guillaume
> doesn't either.

That's true.

>  So, there really isn't much I can do other than to
> suggest contributing code yourself. That is, after all, how all of us
> got involved with PostgreSQL, so you'll have to excuse me for not
> thinking it's particularly weird.
> 

Agreed.

> > It's quite clear that some features are just unfinished prototypes and no
> > one wants to touch this  again (being afraid to crash it completely).
> 
> There are 2 features where that sort-of but not quite applies. The
> Query Builder, which was half-baked and never should have been
> committed in my opinion - what is disabled by default in any build,
> and only affects anything if you explicitly enable it,

I suppose you mean the Database Designer? because the Query Builder is
enabled by default, and is quite stable.

>  and second, the
> Debugger which has never been as stable as it should be, something
> which only came to light *after* Mac and Solaris builds were tested
> where it became apparently that the threading code in it doesn't work
> consistently across all platforms (and that code comes from
> wxWidgets).
> 

I tend to disagree. Seems a good enough feature. But I don't use it
daily, and not on Solaris or Mac.

> But, I've had one of the team at EnterpriseDB working tirelessly for
> the last 2 - 3 months to rewrite that from the ground-up for the next
> release.
> 

Good :)

> > Unfortunately it tells everything about quality of code. But one day it must
> > be refactored and some features must be cleaned up. So why to not start
> > improving pgAdmin today? Is it really matter of time or desire (rather
> > reluctance)?
> 
> Yes, it's time, and lack of people willing to contribute to the
> project. And the fact that there are hundreds of thousands of lines of
> code, and more features being added to PostgreSQL all the time which
> also need to be supported.
> 

Same for me. Lack of time since six or so months. Would love to get back
on track. And get help from other contributors.


-- 
Guillaume
http://blog.guillaume.lelarge.info
http://www.dalibo.com