Обсуждение: Create Table Dialog: Change Column after creation/Reorder Columns
Hi, I want to contribute to pgadmin project, is it ok to start with http://code.pgadmin.org/trac/ticket/90 ( Create Table Dialog: Change Column after creation/Reorder Columns ) Thanks Regards
Вложения
Le 20/06/2010 22:00, Onur GUZEL a écrit : > [...] > I want to contribute to pgadmin project, is it ok to start with > http://code.pgadmin.org/trac/ticket/90 ( Create Table Dialog: Change > Column after creation/Reorder Columns ) > The aim of the ticket is to allow the reordering of columns in a table. This is not a functionality of PostgreSQL. So, you'll have to think a bit on how to do this with pgAdmin. You'll need to find a way to get all the metadatas and the datas of the table, to create a new one, nearly identical (nearly because the order of the columns will be changed, and only that). IOW, the UI needed is just a snap to do (a couple of buttons to bring up or down the selected column), but the underlying work to make it happen could be quite hard. Other than that, you're free to go :) Regards. -- Guillaume http://www.postgresql.fr http://dalibo.com
On Sun, Jun 20, 2010 at 4:46 PM, Guillaume Lelarge <guillaume@lelarge.info> wrote: > Le 20/06/2010 22:00, Onur GUZEL a écrit : >> [...] >> I want to contribute to pgadmin project, is it ok to start with >> http://code.pgadmin.org/trac/ticket/90 ( Create Table Dialog: Change >> Column after creation/Reorder Columns ) >> > > The aim of the ticket is to allow the reordering of columns in a table. > This is not a functionality of PostgreSQL. So, you'll have to think a > bit on how to do this with pgAdmin. You'll need to find a way to get all > the metadatas and the datas of the table, to create a new one, nearly > identical (nearly because the order of the columns will be changed, and > only that). The body of the ticket actually covers both the pre-creation, and post-creation cases. Post-creation is essentially impossible to support without changes in PostgreSQL. > IOW, the UI needed is just a snap to do (a couple of buttons to bring up > or down the selected column), but the underlying work to make it happen > could be quite hard. That's all that's needed for pre-creation reordering, and should be quite straightforward... but... I am intending to redesign the table dialogue for 1.14, so any work on this might go to waste (but, I cannot guarantee I'll have the resources, so it may not!). -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company
Please remember to CC the list! On Sun, Jun 20, 2010 at 5:17 PM, Onur GÜZEL <onur.oguzel@gmail.com> wrote: > Hi, > > Thanks for your quick replies :) > > If it is ok to work on that ticket, i am beginning to add the features. > > Table dialog behaviour on pre-creation needs some buttons (like change > button to show on new table and functionality for this button on > pre-creation) It just needs Up/Down buttons, as we have in some other dialogues. Please copy the design for those, to ensure consistency. > I will try to add Reorder button for Reordering columns on > pre-creation and post-creation, i am going to try drag-n-drop > functionality for columns if i can. It is ok for me if you may suggest > ways (other than drag-n-drop columns) to do that. DnD is nice, but it would need to be implemented in *all* dialogues where we have options to re-order items in a list. Otherwise, the UI becomes inconsistent, and users get confused. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company
Please CC the list when you reply!! On Sun, Jun 20, 2010 at 5:27 PM, Onur GÜZEL <onur.oguzel@gmail.com> wrote: > I agree, i am going to use up/down arrows for reordering of columns on > table dialog UI. > Thanks Cool :-) > On Mon, Jun 21, 2010 at 12:25 AM, Dave Page <dpage@pgadmin.org> wrote: >> Please remember to CC the list! >> >> On Sun, Jun 20, 2010 at 5:17 PM, Onur GÜZEL <onur.oguzel@gmail.com> wrote: >>> Hi, >>> >>> Thanks for your quick replies :) >>> >>> If it is ok to work on that ticket, i am beginning to add the features. >>> >>> Table dialog behaviour on pre-creation needs some buttons (like change >>> button to show on new table and functionality for this button on >>> pre-creation) >> >> It just needs Up/Down buttons, as we have in some other dialogues. >> Please copy the design for those, to ensure consistency. >> >>> I will try to add Reorder button for Reordering columns on >>> pre-creation and post-creation, i am going to try drag-n-drop >>> functionality for columns if i can. It is ok for me if you may suggest >>> ways (other than drag-n-drop columns) to do that. >> >> DnD is nice, but it would need to be implemented in *all* dialogues >> where we have options to re-order items in a list. Otherwise, the UI >> becomes inconsistent, and users get confused. >> >> -- >> Dave Page >> EnterpriseDB UK: http://www.enterprisedb.com >> The Enterprise Postgres Company >> > > > > -- > Onur GUZEL > -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company
Le 20/06/2010 22:52, Dave Page a écrit : > On Sun, Jun 20, 2010 at 4:46 PM, Guillaume Lelarge > <guillaume@lelarge.info> wrote: >> Le 20/06/2010 22:00, Onur GUZEL a écrit : >>> [...] >>> I want to contribute to pgadmin project, is it ok to start with >>> http://code.pgadmin.org/trac/ticket/90 ( Create Table Dialog: Change >>> Column after creation/Reorder Columns ) >>> >> >> The aim of the ticket is to allow the reordering of columns in a table. >> This is not a functionality of PostgreSQL. So, you'll have to think a >> bit on how to do this with pgAdmin. You'll need to find a way to get all >> the metadatas and the datas of the table, to create a new one, nearly >> identical (nearly because the order of the columns will be changed, and >> only that). > > The body of the ticket actually covers both the pre-creation, and > post-creation cases. Post-creation is essentially impossible to > support without changes in PostgreSQL. > I didn't think about pre-creation as in interesting thing. But thinking more about it, you're right. On the post-creation, I don't see it as impossible. I see it as hard work, but possible. >> IOW, the UI needed is just a snap to do (a couple of buttons to bring up >> or down the selected column), but the underlying work to make it happen >> could be quite hard. > > That's all that's needed for pre-creation reordering, and should be > quite straightforward... but... I am intending to redesign the table > dialogue for 1.14, so any work on this might go to waste (but, I > cannot guarantee I'll have the resources, so it may not!). > Yeah, I've been thinking about it too. The pre-creation patch should be easy to code. Could happen before you get to work on the redesign. Unless you want to work it now. -- Guillaume http://www.postgresql.fr http://dalibo.com
On Mon, Jun 21, 2010 at 3:31 AM, Guillaume Lelarge <guillaume@lelarge.info> wrote: > On the post-creation, I don't see it as impossible. I see it as hard > work, but possible. I'd love to know how you'd do that (note that I do not consider "rewrite the table" to be an acceptable solution). -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company
Le 21/06/2010 21:26, Dave Page a écrit : > On Mon, Jun 21, 2010 at 3:31 AM, Guillaume Lelarge > <guillaume@lelarge.info> wrote: > >> On the post-creation, I don't see it as impossible. I see it as hard >> work, but possible. > > I'd love to know how you'd do that (note that I do not consider > "rewrite the table" to be an acceptable solution). > Arg, this was my solution :) Only a PostgreSQL patch could get the kind of solution you want. -- Guillaume http://www.postgresql.fr http://dalibo.com
On Mon, Jun 21, 2010 at 9:37 PM, Guillaume Lelarge <guillaume@lelarge.info> wrote: > Le 21/06/2010 21:26, Dave Page a écrit : >> On Mon, Jun 21, 2010 at 3:31 AM, Guillaume Lelarge >> <guillaume@lelarge.info> wrote: >> >>> On the post-creation, I don't see it as impossible. I see it as hard >>> work, but possible. >> >> I'd love to know how you'd do that (note that I do not consider >> "rewrite the table" to be an acceptable solution). >> > > Arg, this was my solution :) I think that's an acceptable solution, provided it works well. *IFF* it is very very very very clear to the user that this is what happens (extra warning dialog(s), please!). A lot of people have tables small enough that this is not a problem. And remember that it's not quite as trivial as one would initially think - you still need to recreate all indexes and foreign keys and sutff. But it's certainly doable. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On Mon, Jun 21, 2010 at 4:18 PM, Magnus Hagander <magnus@hagander.net> wrote: > I think that's an acceptable solution, provided it works well. *IFF* > it is very very very very clear to the user that this is what happens > (extra warning dialog(s), please!). A lot of people have tables small > enough that this is not a problem. > > And remember that it's not quite as trivial as one would initially > think - you still need to recreate all indexes and foreign keys and > sutff. But it's certainly doable. And views and functions and rules and triggers.... Just handling that lot would be a significant amount of code. My main concerns though, are the space requirements for a large table and the locking that would be required. This is not something you would attempt on a large or busy table unless you were certifiably insane. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company
On Mon, Jun 21, 2010 at 10:34 PM, Dave Page <dpage@pgadmin.org> wrote: > On Mon, Jun 21, 2010 at 4:18 PM, Magnus Hagander <magnus@hagander.net> wrote: > >> I think that's an acceptable solution, provided it works well. *IFF* >> it is very very very very clear to the user that this is what happens >> (extra warning dialog(s), please!). A lot of people have tables small >> enough that this is not a problem. >> >> And remember that it's not quite as trivial as one would initially >> think - you still need to recreate all indexes and foreign keys and >> sutff. But it's certainly doable. > > And views and functions and rules and triggers.... Just handling that > lot would be a significant amount of code. Well, dependency trakcing should help with that -. at least with identifying when it can't be done. But yes, it may take a lot of code. > My main concerns though, are the space requirements for a large table > and the locking that would be required. This is not something you > would attempt on a large or busy table unless you were certifiably > insane. > Agreed - thus the warning requirement. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Magnus Hagander wrote: > On Mon, Jun 21, 2010 at 10:34 PM, Dave Page <dpage@pgadmin.org> wrote: >> On Mon, Jun 21, 2010 at 4:18 PM, Magnus Hagander <magnus@hagander.net> wrote: >> >>> I think that's an acceptable solution, provided it works well. *IFF* >>> it is very very very very clear to the user that this is what happens >>> (extra warning dialog(s), please!). A lot of people have tables small >>> enough that this is not a problem. >>> >>> And remember that it's not quite as trivial as one would initially >>> think - you still need to recreate all indexes and foreign keys and >>> sutff. But it's certainly doable. >> And views and functions and rules and triggers.... Just handling that >> lot would be a significant amount of code. > > Well, dependency trakcing should help with that -. at least with > identifying when it can't be done. But yes, it may take a lot of code. > Sure this will need a lot of code > >> My main concerns though, are the space requirements for a large table >> and the locking that would be required. This is not something you >> would attempt on a large or busy table unless you were certifiably >> insane. >> User should be warned while changing a larger table, like are you sure you want to do this, this will take long time. > > Agreed - thus the warning requirement. > > I am going to use add column and move data method for reordering columns, http://wiki.postgresql.org/wiki/Alter_column_position describes reordering columns or altering column positions methods. Dependency tracking is a really hard work, i agree.
On Tue, Jun 22, 2010 at 1:14 PM, Onur GUZEL <onur.oguzel@gmail.com> wrote: > I am going to use add column and move data method for reordering columns, > http://wiki.postgresql.org/wiki/Alter_column_position describes reordering > columns or altering column positions methods. Dependency tracking is a > really hard work, i agree. Please don't. This would take far more work than it is worth, and there are a ton of ways it can go wrong. The likelihood of me accepting a patch for post-creation rearrangement of columns is extremely low. Pre-creation, is absolutely fine. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company
Dave Page wrote: > Please don't. This would take far more work than it is worth, and > there are a ton of ways it can go wrong. The likelihood of me > accepting a patch for post-creation rearrangement of columns is > extremely low. > > Pre-creation, is absolutely fine. > Post-creation becomes out of scope now. I guess after your suggestion i will just add the functionality of reordering and changing columns on pre-creation. I just dont want to make a mistake by adding an unneeded functionality for pgadmin so thanks for your suggestions.
On Jun 22, 5:36 pm, onur.ogu...@gmail.com (Onur GUZEL) wrote: > Dave Page wrote: > > Please don't. This would take far more work than it is worth, and > > there are a ton of ways it can go wrong. The likelihood of me > > accepting a patch for post-creation rearrangement of columns is > > extremely low. > > > Pre-creation, is absolutely fine. > > Post-creation becomes out of scope now. I guess after your suggestion i > will just add the functionality of reordering and changing columns on > pre-creation. I just dont want to make a mistake by adding an unneeded > functionality for pgadmin so thanks for your suggestions. I do understand the wish to be able to reorder columns in existing tables. I tried to cook something up myself a couple of years back. See the thread on pgsql.admin and what core developers think about it. http://groups.google.at/group/pgsql.admin/browse_thread/thread/528533d669518626 As Magnus said, if we have reliable dependency tracking, we could identify simple cases and reorder. In all other cases just deny the attempt. Regards Erwin