Thread: Paste rows rough patch
Attached is a rough patch to allow pasting of rows into the edit grid. It's not intended to be a final solution, but rather enough to start some discussion. This patch is rather simple - it always deliminates columns by tabs, and stops if it hits a new line. It pastes data starting at the first column of the row the cursor is on. Right now it doesn't pay any attention to the column details, so it will gladly insert data into serial columns or whatever. I figure the proper solution should probably be to obey the copy settings for deliminating columns. As to things like serial & oid columns, how does everyone feel about that? Maybe we could add an option to paste values in, skip the columns, or prompt? Any other thoughts on how this should work? Ed ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
Attachment
> -----Original Message----- > From: pgadmin-hackers-owner@postgresql.org > [mailto:pgadmin-hackers-owner@postgresql.org] On Behalf Of > Edward Di Geronimo Jr. > Sent: 02 May 2006 06:26 > To: pgadmin-hackers@postgresql.org > Subject: [pgadmin-hackers] Paste rows rough patch > > Attached is a rough patch to allow pasting of rows into the > edit grid. > It's not intended to be a final solution, but rather enough > to start some discussion. > > This patch is rather simple - it always deliminates columns > by tabs, and stops if it hits a new line. It pastes data > starting at the first column of the row the cursor is on. > Right now it doesn't pay any attention to the column details, > so it will gladly insert data into serial columns or whatever. > > I figure the proper solution should probably be to obey the > copy settings for deliminating columns. Yes - in particular the quote settings - I have lots of data containing newlines for example, which this won't work with for obvious reasons. > As to things like serial & oid columns, how does everyone > feel about that? Maybe we could add an option to paste values > in, skip the columns, or prompt? OID columns should be ignored, but serial columns should be optional imho - just a simple 'The data you are pasting include values that will be inserted into a serial column. Do you want to skip the serial valules and allow new ones to be assigned? Y/N' prompt at paste time. Regards, Dave
Quoting Dave Page <dpage@vale-housing.co.uk>: > Yes - in particular the quote settings - I have lots of data containing > newlines for example, which this won't work with for obvious reasons. Ok, that's done. Seems to work ok for me, but I don't have any real data that would stress it to test with, just a few test rows. > OID columns should be ignored, but serial columns should be optional > imho - just a simple 'The data you are pasting include values that will > be inserted into a serial column. Do you want to skip the serial valules > and allow new ones to be assigned? Y/N' prompt at paste time. I didn't look too hard, but it looked like OIDs are always going to be the first column when present. Based on that, I updated the patch to skip the first column when there are OIDs. I'm probably not going to have time to deal with the serial columns part in the next few days. The patch should be usable now if people feel like testing it. Ed ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
Attachment
> -----Original Message----- > From: pgadmin-hackers-owner@postgresql.org > [mailto:pgadmin-hackers-owner@postgresql.org] On Behalf Of > Edward Di Geronimo Jr. > Sent: 02 May 2006 22:31 > To: pgadmin-hackers@postgresql.org > Subject: Re: [pgadmin-hackers] Paste rows rough patch > > Quoting Dave Page <dpage@vale-housing.co.uk>: > > > Yes - in particular the quote settings - I have lots of data > > containing newlines for example, which this won't work with > for obvious reasons. > > Ok, that's done. Seems to work ok for me, but I don't have > any real data that would stress it to test with, just a few test rows. > > > OID columns should be ignored, but serial columns should be > optional > > imho - just a simple 'The data you are pasting include values that > > will be inserted into a serial column. Do you want to skip > the serial > > valules and allow new ones to be assigned? Y/N' prompt at > paste time. > > I didn't look too hard, but it looked like OIDs are always > going to be the first column when present. Based on that, I > updated the patch to skip the first column when there are OIDs. > > I'm probably not going to have time to deal with the serial > columns part in the next few days. The patch should be usable > now if people feel like testing it. Hmm, I'm seeing some odd behaviour... - A copy/paste of a single row seems to work in most cases, but: - Sometimes, nothing got pasted into the new row - Sometimes, the entire row got pasted into the end of an existing cell (which had been selected, prior to selecting the '*' row. I couldn't find a pattern to reproduce these, but they did occur a number of times during a few minutes of heavy copy/pasting. - Multi-row pasting doesn't work, but I guess you know that! Regards, Dave.
Dave Page wrote: >Hmm, I'm seeing some odd behaviour... > >- A copy/paste of a single row seems to work in most cases, but: > > - Sometimes, nothing got pasted into the new row > - Sometimes, the entire row got pasted into the end of an existing >cell (which had been selected, prior to selecting the '*' row. > > The code does the pasting based on the grid cursor position, which wx tracks seperately from the highlighted selection. If you have the cursor in say row 10, then click the * to highlight the * row, the cursor stays in row 10. If you then hit paste, the data will go into row 10. Does that help explain things? >- Multi-row pasting doesn't work, but I guess you know that! > > I wasn't planning on handling that case. I didn't even want to think about how to handle the data validation issues on that case. It would only really be useful on tables with no primary key or a (when I'm finished) a serial primary key. I've gotten the feeling that pasting multiple rows is going to be a big ordeal to implement, and therefore wasn't planning on doing it. Ed
> -----Original Message----- > From: pgadmin-hackers-owner@postgresql.org > [mailto:pgadmin-hackers-owner@postgresql.org] On Behalf Of > Edward Di Geronimo Jr. > Sent: 03 May 2006 16:31 > To: pgadmin-hackers@postgresql.org > Subject: Re: [pgadmin-hackers] Paste rows rough patch > > Dave Page wrote: > > >Hmm, I'm seeing some odd behaviour... > > > >- A copy/paste of a single row seems to work in most cases, but: > > > > - Sometimes, nothing got pasted into the new row > > - Sometimes, the entire row got pasted into the end of an existing > >cell (which had been selected, prior to selecting the '*' row. > > > > > The code does the pasting based on the grid cursor position, > which wx tracks seperately from the highlighted selection. If > you have the cursor in say row 10, then click the * to > highlight the * row, the cursor stays in row 10. If you then > hit paste, the data will go into row 10. Does that help > explain things? Certainly explains it, but I'm sure it will confuse the heck out of some users. In testing on Windows, I see that a cell can be active (ie. Have a thick border), or have focus (ie. The cursor is flashing in it). It seems to me that we should only paste directly into the cell in the latter case - in the former, or any other case, the paste goes to the '*' row. Is that doable? Does it sound sensible to you? > >- Multi-row pasting doesn't work, but I guess you know that! > > > > > I wasn't planning on handling that case. I didn't even want > to think about how to handle the data validation issues on > that case. It would only really be useful on tables with no > primary key or a (when I'm > finished) a serial primary key. I've gotten the feeling that > pasting multiple rows is going to be a big ordeal to > implement, and therefore wasn't planning on doing it. OK, np. Cheers, Dave.
Dave Page wrote: >In testing on Windows, I see that a cell can be active (ie. Have a thick >border), or have focus (ie. The cursor is flashing in it). It seems to >me that we should only paste directly into the cell in the latter case - >in the former, or any other case, the paste goes to the '*' row. Is that >doable? Does it sound sensible to you? > > That sounds reasonable. My original plan was to always paste into the * row, but then I thought the option of pasting into the current row would be nice. I hadn't realized the awkwardness of the selection handling at the time. Ed