Thread: ...
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
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
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
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
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
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
<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>
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