Обсуждение: Usability improvment ideas
<div class="WordSection1"><p class="MsoNormal"><span lang="EN-US">Hi pgadmin team,</span><p class="MsoNormal"><span lang="EN-US"> </span><pclass="MsoNormal"><span lang="EN-US">I am not sure if this mailing list is suitable for giving feedbackon pgadmin,</span><p class="MsoNormal"><span lang="EN-US">so please redirect me to a better place if necessary.</span><pclass="MsoNormal"><span lang="EN-US"> </span><p class="MsoNormal"><span lang="EN-US">Pgadmin itself seemsto be a really nice tool, </span><p class="MsoNormal"><span lang="EN-US">but I think that there is potential to improveits usability with minor development effort.</span><p class="MsoNormal"><span lang="EN-US"> </span><p class="MsoNormal"><spanlang="EN-US">1] a "run current query" shortcut</span><p class="MsoNormal"><span lang="EN-US">2] an"abort query" shortcut</span><p class="MsoNormal"><span lang="EN-US">3] improved shortcut for comment/uncomment multiplelines</span><p class="MsoNormal"><span lang="EN-US"> </span><p class="MsoNormal"><span lang="EN-US">1] a "run currentquery" shortcut</span><p class="MsoNormal"><span lang="EN-US"> </span><p class="MsoNormal"><span lang="EN-US">Wheneveryou have more than one query within the query editor, </span><p class="MsoNormal"><span lang="EN-US">itis necessary to select the query in order to execute it.</span><p class="MsoNormal"><span lang="EN-US">Itwould be better if it’s possible to do the same without requiring an initial query selection.</span><p class="MsoNormal"><spanlang="EN-US"> </span><p class="MsoNormal"><span lang="EN-US">My proposal would be to add ctrl+F5 asshortcut, which runs the query surrounding the current cursor position.</span><p class="MsoNormal"><span lang="EN-US">ctrl+F7would do the same for an explain plan.</span><p class="MsoNormal"><span lang="EN-US"> </span><p class="MsoNormal"><spanlang="EN-US">It would not break the current behavior because the old way would still exist.</span><pclass="MsoNormal"><span lang="EN-US">This is most probably easy to implement. </span><p class="MsoNormal"><spanlang="EN-US"> </span><p class="MsoNormal"><span lang="EN-US">Don’t think about a fancy algorithm tofind the proper query surrounding the cursor.</span><p class="MsoNormal"><span lang="EN-US">Implement it the simplest availableway: an empty line above or below is the border to identify the query.</span><p class="MsoNormal"><span lang="EN-US"> </span><pclass="MsoNormal"><span lang="EN-US">If a line contains only whitespaces (tab, space,...) its qualifiedto limit the query scope.</span><p class="MsoNormal"><span lang="EN-US">An comment-only line should not be treatedas query border.</span><p class="MsoNormal"><span lang="EN-US">(Complex queries might have full line comments withinthe query.)</span><p class="MsoNormal"><span lang="EN-US"> </span><p class="MsoNormal"><span lang="EN-US">Rationale:</span><pclass="MsoNormal"><span lang="EN-US">It allows a user to constantly spam "run query" or "explainquery" without moving his hands from the keyboard.</span><p class="MsoNormal"><span lang="EN-US"> </span><p class="MsoNormal"><spanlang="EN-US">I must admit, that it’s hard to see the value without the ability to get a feeling forit.</span><p class="MsoNormal"><span lang="EN-US">I am not aware of a decent postgresql query tool caring about this issue.</span><pclass="MsoNormal"><span lang="EN-US"> </span><p class="MsoNormal"><span lang="EN-US">Optional:</span><p class="MsoNormal"><spanlang="EN-US">The ability to configure the shortcut, because to be honest I like toads ctrl+enter morethan the idea of ctrl+F5.</span><p class="MsoNormal"><span lang="EN-US">You might think that this makes no difference,</span><p class="MsoNormal"><span lang="EN-US">but for hitting ctrl+F5 I need to move my arm,</span><p class="MsoNormal"><spanlang="EN-US">while the other one is reachable with minimal effort (at least at my german keyboardlayout)</span><p class="MsoNormal"><span lang="EN-US">The same applies to ctrl+e vs. ctrl+F7.</span><p class="MsoNormal"><spanlang="EN-US"> </span><p class="MsoNormal"><span lang="EN-US">2] an "abort query" shortcut</span><pclass="MsoNormal"><span lang="EN-US"> </span><p class="MsoNormal"><span lang="EN-US">How about using theescape key to abort the currently running query?</span><p class="MsoNormal"><span lang="EN-US"> </span><p class="MsoNormal"><spanlang="EN-US">3] improved shortcut for comment/uncomment multiple lines</span><p class="MsoNormal"><spanlang="EN-US"> </span><p class="MsoNormal"><span lang="EN-US">This is a controversial topic, becauseto be honest I’m not sure if my proposal is a good one.</span><p class="MsoNormal"><span lang="EN-US">The only thingI know is that your current mechanic feels awkward.</span><p class="MsoNormal"><span lang="EN-US"> </span><p class="MsoNormal"><spanlang="EN-US">I think what I mostly dislike is: </span><p class="MsoNormal"><span lang="EN-US">Thecomment of the first line does not appear at the beginning of the first line.</span><p class="MsoNormal"><spanlang="EN-US">It is always added to the start of the selection.</span><p class="MsoNormal"><span lang="EN-US"> </span><pclass="MsoNormal"><span lang="EN-US">Currently I use comment/uncomment only within eclipse and toad.</span><pclass="MsoNormal"><span lang="EN-US">Toad is like pgadmin, but it adds the first comment at the start of thefirst line.</span><p class="MsoNormal"><span lang="EN-US"> </span><p class="MsoNormal"><span lang="EN-US">But in the endit would be even nicer if it’s even smarter as it is within eclipse.</span><p class="MsoNormal"><span lang="EN-US">Itallows using both actions with only one shortcut.</span><p class="MsoNormal"><span lang="EN-US"> </span><pclass="MsoNormal"><span lang="EN-US">If all lines start with -- => uncomment them. (ignore whitespacesin front of --)</span><p class="MsoNormal"><span lang="EN-US">If one line within the selection does not startwith -- => add a comment to all of them.</span><p class="MsoNormal"><span lang="EN-US"> </span><p class="MsoNormal"><spanlang="EN-US">This behavior might sound little bit odd, </span><p class="MsoNormal"><span lang="EN-US">butafter using both behaviors regular, </span><p class="MsoNormal"><span lang="EN-US">I would always preferthe smarter eclipse way.</span><p class="MsoNormal"><span lang="EN-US"> </span><p class="MsoNormal"><span lang="EN-US">Regards,</span><pclass="MsoNormal"><span lang="EN-US">Bernhard</span><p class="MsoNormal"><span lang="EN-US"> </span><pclass="MsoNormal"><span lang="EN-US">Sorry for not trying to implement it on my own.</span><p class="MsoNormal"><spanlang="EN-US">But after 10 years of avoiding c, I doubt that the resulting code would be helpful.</span></div>
Hi, Le 14/03/2011 23:06, Bernhard Neuhauser a écrit : > [...] > I am not sure if this mailing list is suitable for giving feedback on pgadmin, > so please redirect me to a better place if necessary. > No, it's the good list. > Pgadmin itself seems to be a really nice tool, > but I think that there is potential to improve its usability with minor development effort. > > 1] a "run current query" shortcut > 2] an "abort query" shortcut > 3] improved shortcut for comment/uncomment multiple lines > > 1] a "run current query" shortcut > > Whenever you have more than one query within the query editor, > it is necessary to select the query in order to execute it. > It would be better if it's possible to do the same without requiring an initial query selection. > > My proposal would be to add ctrl+F5 as shortcut, which runs the query surrounding the current cursor position. > ctrl+F7 would do the same for an explain plan. > > It would not break the current behavior because the old way would still exist. > This is most probably easy to implement. > > Don't think about a fancy algorithm to find the proper query surrounding the cursor. > Implement it the simplest available way: an empty line above or below is the border to identify the query. > It may be a simple way to do it, but it's not the usual one. Everyone using PostgreSQL and psql knows that what finishes a query is a colon. So, to do it correctly, we would need to search the previous and the next colons, and execute the query between them. But searching a colon is not an easy thing (think colon in string, a string being between simple quotes or dollar quoting... just a nightmare). > If a line contains only whitespaces (tab, space,...) its qualified to limit the query scope. > An comment-only line should not be treated as query border. > (Complex queries might have full line comments within the query.) > This "view" of a query is too limited. > Rationale: > It allows a user to constantly spam "run query" or "explain query" without moving his hands from the keyboard. > > I must admit, that it's hard to see the value without the ability to get a feeling for it. > I am not aware of a decent postgresql query tool caring about this issue. > Actually, I find the idea of executing a single query without selecting it interesting. What I don't know yet is how to do it easily. > Optional: > The ability to configure the shortcut, because to be honest I like toads ctrl+enter more than the idea of ctrl+F5. > You might think that this makes no difference, > but for hitting ctrl+F5 I need to move my arm, > while the other one is reachable with minimal effort (at least at my german keyboard layout) > The same applies to ctrl+e vs. ctrl+F7. > > 2] an "abort query" shortcut > > How about using the escape key to abort the currently running query? > Yeah, like it. > 3] improved shortcut for comment/uncomment multiple lines > > This is a controversial topic, because to be honest I'm not sure if my proposal is a good one. > The only thing I know is that your current mechanic feels awkward. > > I think what I mostly dislike is: > The comment of the first line does not appear at the beginning of the first line. > It is always added to the start of the selection. > I've never tried it, but I understand why you find that weird. > Currently I use comment/uncomment only within eclipse and toad. > Toad is like pgadmin, but it adds the first comment at the start of the first line. > > But in the end it would be even nicer if it's even smarter as it is within eclipse. > It allows using both actions with only one shortcut. > > If all lines start with -- => uncomment them. (ignore whitespaces in front of --) > If one line within the selection does not start with -- => add a comment to all of them. > > This behavior might sound little bit odd, > but after using both behaviors regular, > I would always prefer the smarter eclipse way. > Seems interesting. I need to think about it. > Regards, > Bernhard > > Sorry for not trying to implement it on my own. > But after 10 years of avoiding c, I doubt that the resulting code would be helpful. > -- Guillaumehttp://www.postgresql.frhttp://dalibo.com
Hi again, >This "view" of a query is too limited. Actually, this "view" of a query is more powerful as you expect. Because it also allows you to execute pl/xSQL snippets in the same way. Basically it allows the "user" to decide if he wants one query or a group of queries executed together. This is one of the reasons why some oracle people tend to avoid empty lines inside db packages. If you use an empty -- comment it feels like an empty line but still allows you to execute the whole block using a shortcut. Think about 3 simple queries you need to invoke frequently because you are testing something and need them to reset something. You wrap them inside begin + end and voila its executed as single "block". So most probably my short description is misleading: "run current query" Maybe it is better to call it "run current statement block" I just tried http://www.squirrelsql.org/ with pg. It seems to have the behavior I described. So maybe you can use this tool to play little bit with the possibilities of such an implementation. --- The reason why I proposed this 3 things was, because I think they are real "quick-wins". They have potential to improve usability without the need of investing to much valuable dev time. And even if you think that the quickest implementation is not the perfect thing. Keep in mind, that a more complex implementation might be lots of additional work without a proof of becoming better. I honestly ask you to give the "simple" thing a chance. There is still the possibility to improve it in future. Regards, Bernhard
<br /><font face="sans-serif" size="2">Hi all,</font><br /><font size="3"><tt>i second the request of Bernhard, especiallyfor the "run current query" or better "run current statement block"<br /></tt></font><br /><font size="3"><tt>>This"view" of a query is too limited.<br /> There's no need for anything complicated, just put the cursorwithin a code block and execute everything from previuos blank line to next blank line. That's incredibly powerfulespecially when prototyping and the missing of this feature is the reason i use pgadmin only for administration andother tools like the mentioned squirrel for query building and running.</tt></font><br /><br /><font size="3"><tt>Regards,</tt></font><br /><font size="3"><tt>Gabriele</tt></font>
On Wed, May 11, 2011 at 8:23 AM, <gabriele.garuglieri@infoblu.it> wrote: > > Hi all, > i second the request of Bernhard, especially for the "run current query" or > better "run current statement block" > >>This "view" of a query is too limited. > There's no need for anything complicated, just put the cursor within a code > block and execute everything from previuos blank line to next blank line. > That's incredibly powerful especially when prototyping and the missing of > this feature is the reason i use pgadmin only for administration and other > tools like the mentioned squirrel for query building and running. Hmm, that would certainly involve far less pain than building a parser to handle "execute current query". We could pretty easily add options for "execute current line" and "execute current paragraph" (I'd find those very useful in fact). -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
<br /><font size="2"><tt>Dave Page <dpage@pgadmin.org> scritti il 11/05/2011 10:12:33<br /><br /> > We could prettyeasily add options<br /> > for "execute current line" and "execute current paragraph" (I'd find<br /> > thosevery useful in fact).<br /> > <br /></tt></font><br /><font size="2"><tt>Those would be greatly welcome!!</tt></font><br/><br /><font size="2"><tt>Thanks,</tt></font><br /><font size="2"><tt>Gabriele</tt></font>
On Wed, May 11, 2011 at 1:18 PM, Bob McConnell <rvm@cbord.com> wrote: > From: gabriele.garuglieri > >> Dave Page <dpage@pgadmin.org> scritti il 11/05/2011 10:12:33 >> >>> We could pretty easily add options >>> for "execute current line" and "execute current paragraph" (I'd find >>> those very useful in fact). >> >> Those would be greatly welcome!! > > If I might add a suggestion. I have occasion to use Sybase ASA and the > Interactive SQL tool that comes with it. In that application, when I hit > F9 it will execute all of the SQL statements in that window. But if I > highlight one or more of several statements, as if I were copying them, > then hit F9, it will only execute the highlighted statements. pgAdmin already does that (though, with F5, not F9). -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
From: gabriele.garuglieri > Dave Page <dpage@pgadmin.org> scritti il 11/05/2011 10:12:33 > >> We could pretty easily add options >> for "execute current line" and "execute current paragraph" (I'd find >> those very useful in fact). > > Those would be greatly welcome!! If I might add a suggestion. I have occasion to use Sybase ASA and the Interactive SQL tool that comes with it. In that application, when I hit F9 it will execute all of the SQL statements in that window. But if I highlight one or more of several statements, as if I were copying them, then hit F9, it will only execute the highlighted statements. Bob McConnell
Just an observation..... :) With the 1.14 stream of pgadmin3, I notice that the dialog for creation of columns moves the type to a different tab thanthe name, requiring much more work to create the columns. Is there a reason why this was done? The old way seemed to work nicer for me - ie: most of the needed bits were all on onetab to quickly add a column, go to other tabs only if needed. Regards, Peter. -----Original Message----- From: pgadmin-support-owner@postgresql.org [mailto:pgadmin-support-owner@postgresql.org] On Behalf Of Dave Page Sent: Wednesday, May 11, 2011 7:27 AM To: Bob McConnell Cc: gabriele.garuglieri@infoblu.it; bneuhauser@real.com; guillaume@lelarge.info; pgadmin-support@postgresql.org Subject: Re: [pgadmin-support] Usability improvment ideas On Wed, May 11, 2011 at 1:18 PM, Bob McConnell <rvm@cbord.com> wrote: > From: gabriele.garuglieri > >> Dave Page <dpage@pgadmin.org> scritti il 11/05/2011 10:12:33 >> >>> We could pretty easily add options >>> for "execute current line" and "execute current paragraph" (I'd find >>> those very useful in fact). >> >> Those would be greatly welcome!! > > If I might add a suggestion. I have occasion to use Sybase ASA and the > Interactive SQL tool that comes with it. In that application, when I hit > F9 it will execute all of the SQL statements in that window. But if I > highlight one or more of several statements, as if I were copying them, > then hit F9, it will only execute the highlighted statements. pgAdmin already does that (though, with F5, not F9). -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-support
On Thu, May 12, 2011 at 5:41 PM, Belbin, Peter <Peter.Belbin@paetec.com> wrote: > Just an observation..... :) > > > With the 1.14 stream of pgadmin3, I notice that the dialog for creation of columns moves the type to a different tab thanthe name, requiring much more work to create the columns. That does seem like a usability regression Guillaume. Can you look at that please? The other one that's been bugging me is that the Service field on the server dialog is now above the host/address field, which also seems wrong. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
One other thing... For me, I have had this issue for a very long time: If I am using pgadmin and it looses it's connection to the server, asking it to re connect always fails, and I have to killthe app and restart. In a case where there is no nat or firewall between me and the server, this never seems to be a problem. However, where there are nats or firewalls, it seems like the connection gets terminated somewhere, and pgadmin just doesnot do a good job of reconnecting. It's the main rough spot for me. Regards, Peter. -----Original Message----- From: pgadmin-support-owner@postgresql.org [mailto:pgadmin-support-owner@postgresql.org] On Behalf Of Belbin, Peter Sent: Thursday, May 12, 2011 11:42 AM To: 'Dave Page'; Bob McConnell Cc: gabriele.garuglieri@infoblu.it; bneuhauser@real.com; guillaume@lelarge.info; pgadmin-support@postgresql.org Subject: Re: [pgadmin-support] Usability improvment ideas Just an observation..... :) With the 1.14 stream of pgadmin3, I notice that the dialog for creation of columns moves the type to a different tab thanthe name, requiring much more work to create the columns. Is there a reason why this was done? The old way seemed to work nicer for me - ie: most of the needed bits were all on onetab to quickly add a column, go to other tabs only if needed. Regards, Peter. -----Original Message----- From: pgadmin-support-owner@postgresql.org [mailto:pgadmin-support-owner@postgresql.org] On Behalf Of Dave Page Sent: Wednesday, May 11, 2011 7:27 AM To: Bob McConnell Cc: gabriele.garuglieri@infoblu.it; bneuhauser@real.com; guillaume@lelarge.info; pgadmin-support@postgresql.org Subject: Re: [pgadmin-support] Usability improvment ideas On Wed, May 11, 2011 at 1:18 PM, Bob McConnell <rvm@cbord.com> wrote: > From: gabriele.garuglieri > >> Dave Page <dpage@pgadmin.org> scritti il 11/05/2011 10:12:33 >> >>> We could pretty easily add options >>> for "execute current line" and "execute current paragraph" (I'd find >>> those very useful in fact). >> >> Those would be greatly welcome!! > > If I might add a suggestion. I have occasion to use Sybase ASA and the > Interactive SQL tool that comes with it. In that application, when I hit > F9 it will execute all of the SQL statements in that window. But if I > highlight one or more of several statements, as if I were copying them, > then hit F9, it will only execute the highlighted statements. pgAdmin already does that (though, with F5, not F9). -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-support -- Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-support
Le 05/13/2011 06:03 PM, Dave Page a écrit : > On Thu, May 12, 2011 at 5:41 PM, Belbin, Peter <Peter.Belbin@paetec.com> wrote: >> Just an observation..... :) >> >> >> With the 1.14 stream of pgadmin3, I notice that the dialog for creation of columns moves the type to a different tab thanthe name, requiring much more work to create the columns. > > That does seem like a usability regression Guillaume. Can you look at > that please? Yeah, but it means we'll lose the consistency. I know it doesn't feel right, but if we allow the type to be on the first tab, we'll get lots of request for that kind of thing for $object. > The other one that's been bugging me is that the Service > field on the server dialog is now above the host/address field, which > also seems wrong. > Will look into it. -- Guillaumehttp://www.postgresql.frhttp://dalibo.com
On Mon, May 16, 2011 at 8:52 AM, Guillaume Lelarge <guillaume@lelarge.info> wrote: > Le 05/13/2011 06:03 PM, Dave Page a écrit : >> On Thu, May 12, 2011 at 5:41 PM, Belbin, Peter <Peter.Belbin@paetec.com> wrote: >>> Just an observation..... :) >>> >>> >>> With the 1.14 stream of pgadmin3, I notice that the dialog for creation of columns moves the type to a different tabthan the name, requiring much more work to create the columns. >> >> That does seem like a usability regression Guillaume. Can you look at >> that please? > > Yeah, but it means we'll lose the consistency. I know it doesn't feel > right, but if we allow the type to be on the first tab, we'll get lots > of request for that kind of thing for $object. I'm normally the first guy to bleat about consistency, but this really does feel like a big regression in usability to me - this is one of the few (the only?) dialog that people are likely to open over and over again when creating another object. We already know that is cumbersome (that's why there's a complete redesign of the table dialogue on the TODO) - this will make it worse. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 05/16/2011 09:57 AM, Dave Page wrote: > On Mon, May 16, 2011 at 8:52 AM, Guillaume Lelarge > <guillaume@lelarge.info> wrote: >> Le 05/13/2011 06:03 PM, Dave Page a écrit : >>> On Thu, May 12, 2011 at 5:41 PM, Belbin, Peter <Peter.Belbin@paetec.com> wrote: >>>> Just an observation..... :) >>>> >>>> >>>> With the 1.14 stream of pgadmin3, I notice that the dialog for creation of columns moves the type to a different tabthan the name, requiring much more work to create the columns. >>> >>> That does seem like a usability regression Guillaume. Can you look at >>> that please? >> >> Yeah, but it means we'll lose the consistency. I know it doesn't feel >> right, but if we allow the type to be on the first tab, we'll get lots >> of request for that kind of thing for $object. > > I'm normally the first guy to bleat about consistency, but this really > does feel like a big regression in usability to me - this is one of > the few (the only?) dialog that people are likely to open over and > over again when creating another object. We already know that is > cumbersome (that's why there's a complete redesign of the table > dialogue on the TODO) - this will make it worse. > Done. Actually, I had to move three fields (datatype, length, and precision). -- Guillaumehttp://www.postgresql.frhttp://dalibo.com
On 05/16/2011 09:52 AM, Guillaume Lelarge wrote: > Le 05/13/2011 06:03 PM, Dave Page a écrit : >> On Thu, May 12, 2011 at 5:41 PM, Belbin, Peter <Peter.Belbin@paetec.com> wrote: >>> Just an observation..... :) >>> >>> >>> With the 1.14 stream of pgadmin3, I notice that the dialog for creation of columns moves the type to a different tabthan the name, requiring much more work to create the columns. >> >> That does seem like a usability regression Guillaume. Can you look at >> that please? > > Yeah, but it means we'll lose the consistency. I know it doesn't feel > right, but if we allow the type to be on the first tab, we'll get lots > of request for that kind of thing for $object. > >> The other one that's been bugging me is that the Service >> field on the server dialog is now above the host/address field, which >> also seems wrong. >> > > Will look into it. > Done. -- Guillaumehttp://www.postgresql.frhttp://dalibo.com
On Tue, May 17, 2011 at 8:27 PM, Guillaume Lelarge <guillaume@lelarge.info> wrote: > On 05/16/2011 09:57 AM, Dave Page wrote: >> On Mon, May 16, 2011 at 8:52 AM, Guillaume Lelarge >> <guillaume@lelarge.info> wrote: >>> Le 05/13/2011 06:03 PM, Dave Page a écrit : >>>> On Thu, May 12, 2011 at 5:41 PM, Belbin, Peter <Peter.Belbin@paetec.com> wrote: >>>>> Just an observation..... :) >>>>> >>>>> >>>>> With the 1.14 stream of pgadmin3, I notice that the dialog for creation of columns moves the type to a different tabthan the name, requiring much more work to create the columns. >>>> >>>> That does seem like a usability regression Guillaume. Can you look at >>>> that please? >>> >>> Yeah, but it means we'll lose the consistency. I know it doesn't feel >>> right, but if we allow the type to be on the first tab, we'll get lots >>> of request for that kind of thing for $object. >> >> I'm normally the first guy to bleat about consistency, but this really >> does feel like a big regression in usability to me - this is one of >> the few (the only?) dialog that people are likely to open over and >> over again when creating another object. We already know that is >> cumbersome (that's why there's a complete redesign of the table >> dialogue on the TODO) - this will make it worse. >> > > Done. Actually, I had to move three fields (datatype, length, and > precision). Thanks. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company